You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not documented anywhere how the session updates should behave.
Currently, most, if not all, implementations would create a new session, if one does not exist.
In effect, it works like an upsert.
But I am not sure if this is correct.
Otherwise, it can lead to race conditions:
One tab clicks logout (and destroys the session)
Meanwhile, another tab sends a request, which updates the session.
Or:
The record is expired (has reached TTL)
Another update (race condition) arrives and updates the expired session. This can be especially true in cases when using arc table (DynamoDB), which may not reap expired documents for days).
I think implementations should use optimistic locking and throw when updating a non-existent record.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
It is not documented anywhere how the session updates should behave.
Currently, most, if not all, implementations would create a new session, if one does not exist.
In effect, it works like an upsert.
But I am not sure if this is correct.
Otherwise, it can lead to race conditions:
Or:
I think implementations should use optimistic locking and throw when updating a non-existent record.
remix/packages/remix-cloudflare/sessions/workersKVStorage.ts
Lines 71 to 75 in 0dc1da2
remix/packages/remix-architect/sessions/arcTableSessionStorage.ts
Lines 103 to 115 in 0dc1da2
remix/packages/remix-node/sessions/fileStorage.ts
Lines 85 to 89 in 0dc1da2
Beta Was this translation helpful? Give feedback.
All reactions