Record "disappears" from client side storage?

[Cantor, Scott]

I have a few of those messages in the log, 5-10 a day.

I don't see any obvious way for the record to be there at the start of the request, and not by the end, other than edge cases like a session timing out in between but I suppose it's not impossible for that to happen, and 5-10 out of 200,000 or so is not a lot.

Since it forced them through a login, that means there was no usable AuthenticationResult stored in the session to start with, which would make it an "empty" session in some sense, and sessions that don't get updated eventually do expire, just to free memory up. Usually they expire in the dead periods between requests of course.

But it's not impossible for that to happen at exactly the moment in between the front and back half of a request (especially with user input and Duo involved, that's not milliseconds).

When the code tries to update the record, it passes in a version number of what the record was in memory and updates it only if the versions match so it doesn't get out of sync. That error line matches what happens if that update call returns null, which means it wasn't a version mismatch, there really was no (unexpired) record there to update.

The overall appearance in your case is of a race condition between requests. It doesn't appear to have even audited the first ticket issued event before it's handling the second request. It maybe hasn't even updated the session with the result of the first login to allow for it to be reused either.

Or maybe you just don't have the audit output ending up in the process log, normally it does. It's a better idea to do it because of the proof of timing between events. Or maybe CAS is just broken and the auditing doesn't work, I wouldn't know.

That part makes less sense to me than the storage behavior, at least that could be explained in theory by a timeout.

-- Scott