Share in-flight default session init#613
Merged
ghostwriternr merged 3 commits intomainfrom Apr 23, 2026
Merged
Conversation
🦋 Changeset detectedLatest commit: bca7eda The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
Contributor
📦 Preview BuildVersion: Install the SDK preview:
|
25e6f28 to
2d9bc5c
Compare
Parallel operations on a fresh sandbox each fired their own createSession RPC; the first succeeded and the rest got SessionAlreadyExistsError handled as a no-op. Callers that target the same default session id now share one in-flight initialization promise. The slot is keyed by session id so that if the sandbox is named mid-flight, a caller expecting the new name starts its own init. Setup also writes to storage before updating the in-memory session id, so a storage failure after createSession succeeds retries on the next operation rather than treating setup as complete.
The in-flight session initialization promise introduced in the previous commit could interleave with onStop. If createSession returned successfully after onStop cleared the default session, the init's continuation would re-persist the stale session id, and any concurrent caller could join the stale promise and receive it. The next DO wake would then fast-path through a session that no longer exists in the fresh container. onStop now advances a container generation counter and clears the in-flight slot before any await. The init captures the generation at start and checks it between the container RPC and the state write. A container stop during init fails the current attempt so the next caller starts fresh against the new container.
d76e9dc to
bca7eda
Compare
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Parallel operations on a fresh sandbox each fired their own
createSessionRPC; the first succeeded and the rest gotSessionAlreadyExistsErrorhandled as a no-op. Sequential callers already short-circuited on the second call, so the duplication was bounded to the narrow window before the first call settled, but there's no reason to let it happen. The first caller now records the in-flight initialization promise, and later callers that arrive before it settles share that promise.Setup was also writing the session id to the in-memory field before persisting it to DO storage. That ordering means a storage write that fails after the container has accepted the create call would leave the DO thinking setup completed. Swapped to persist-first, cache-second so a failed persistence retries on the next operation.