SessionManagementService.RemoveSessionsAsync strange failure

[0472d]

We have implemented our own session clean up using a windows service but still using the SessionManagementService.RemoveSessionsAsync. See https://github.com/orgs/DuendeSoftware/discussions/576#discussioncomment-17854434 for a discussion why. It does seem to have fixed our issue with ID Server ramping up DB connections. Since implementing this they have stayed below 50 connections for each server. So we think we are on the right lines for why it maxed out connections.

However we are seeing something very bizarre. After a day or so successful running the service stops deleting sessions. We have switched on logging and have found that every delete call is logging

Error removing 1 server-side sessions from database for SessionFilter { SubjectId: null, SessionId: "xxxx" }: "The database operation was expected to affect 1 row(s), but actually affected 0 row(s); data may have been modified or deleted since entities were loaded. See https://go.microsoft.com/fwlink/?LinkId=527962 for information on understanding and handling optimistic concurrency exceptions."

Once this starts occurring, the only way we have found to fix this is to recompile the windows service and republish to the server. A simple restart of the service, or republishing the same version doesnt fix this. We get the same error. I have used SQL profiler, I cant see any duplicate calls, just missing the delete which I assume is due to the concurrency check stopping it being called.

Have you got any ideas why the concurrency check seems to get stuck and returns all as invalid until we publish a new version of the same code?

[ProgrammerAL]

Our initial suspicion of this issue is either related to EF entity tracking, or maybe some other system is caching values.

If you are using EF change tracking, that could be storing the entities in memory too long and are sharing them across DB contexts. If it’s simple for you to do, you can test this by querying the entities as a No-Tracking query, https://learn.microsoft.com/en-us/ef/core/querying/tracking#no-tracking-queries, then running the delete immediately after that with a separate query.

Alternatively there could be some other system caching values for a long time. You said the problem does not resolve after a restart, but is resolved after recompiling and redeploying the application. Since that takes a while to do, it adds to the theory that something else is caching the values.