MESOP_CONCURRENT_UPDATES_ENABLED - with non-default state-sessions

[richard-to]

Just realized that this could cause some problems with how state session backends currently work. Right now the token IDs change after every request. The old state / token pair also get deleted after every request. After this first concurrent request, the session token will not be found and force a retry.

I was able to verify this behavior using the Memory backend. There was a request retry logged.

[wwwillchen]

That's a good point, I think we'll need to fix this before making MESOP_CONCURRENT_UPDATES_ENABLED the default, but I imagine this combination will be pretty rare for a while.

[richard-to]

Yeah, I've been thinking of how to resolve this. I'm thinking what we can do is stop deleting the state session from the cache right away.

We can probably mark it as "accessed" and then perform a deletion of all "accessed" state sessions at a quicker interval than the stale sessions which we currently delete at a 10 minute interval.

Alternatively, we could simplify it further, and just delete all state at a quicker interval. The issue with this is that we may need to balance inactivity time. However, some slight extra latency for inactive sessions may be ok.

I think that could be enough to make the concurrent updates behave the same as with out sessions.