Document StateStore instance property design to clarify race condition safety #401
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
StateStoreclass uses instance properties (state,codeVerifier) that could appear to have race conditions when multiple calls toset()occur beforetoString()is called. However, each OAuth2 authentication flow creates its ownStateStoreinstance, making this design safe.Changes
Added documentation to clarify the design pattern:
stateandcodeVerifiertrack the "current" state for the nexttoString()call, with each OAuth2Strategy creating its own instance per requestset()method: Explained the dual purpose of setting instance properties for serialization while maintaining collections for validationtoString()method: Clarified that only instance properties are serialized (not the entire collection), which is intentional since each flow has its own instanceThe documentation makes explicit that this pattern prevents race conditions rather than creating them.
💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.