Skip to content

refactor(server): resume suspended sessions unconditionally in the fetch entry - #41938

Merged
kitlangton merged 1 commit into
v2from
unconditional-embed-resume
Aug 12, 2026
Merged

refactor(server): resume suspended sessions unconditionally in the fetch entry#41938
kitlangton merged 1 commit into
v2from
unconditional-embed-resume

Conversation

@kitlangton

Copy link
Copy Markdown
Contributor

What

Removes ServerFetch.BootOptions.resumeSuspendedSessions (added in #41896) and makes the web-standard fetch entry resume execution-claimed Sessions unconditionally after the layer builds, matching ServerProcess.start (which has resumed unconditionally since #36105).

Why

The flag was speculative API: the resume sweep filters live claims and is a no-op when nothing is suspended, so there is no embedder that wants false — a runtime with a fresh :memory: database has nothing to resume, and a runtime with durable storage wants orphaned turns replayed. The only caller that would ever exist passes true (the workerd profile in #41918, which simplifies further on top of this).

Testing

packages/server suite green (32 tests) including the ServerFetch handler tests.

…tch entry
The Node server process has resumed unconditionally since the mechanism
existed; the sweep filters live claims and is a no-op when nothing is
suspended, so an opt-in flag whose only conceivable caller passes true
was speculative API. ServerFetch.make now resumes exactly as
ServerProcess.start does, and the empty BootOptions bag goes away.
@kitlangton
kitlangton enabled auto-merge (squash) August 12, 2026 03:22
@kitlangton
kitlangton merged commit 5b7b183 into v2Aug 12, 2026
10 checks passed
@kitlangton
kitlangton deleted the unconditional-embed-resume branch August 12, 2026 03:31
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@kitlangton