Skip to content

refactor: make ExecutionContext ALS the single source of truth#431

Merged
james-elicx merged 2 commits intomainfrom
refactor/execution-context-als-cleanup
Mar 11, 2026
Merged

refactor: make ExecutionContext ALS the single source of truth#431
james-elicx merged 2 commits intomainfrom
refactor/execution-context-als-cleanup

Conversation

@james-elicx
Copy link
Copy Markdown
Collaborator

Summary

  • Remove `ctx` as an explicit parameter from internal functions (`triggerBackgroundRegeneration`, generated `_handleRequest`) so all downstream code consistently retrieves the Workers `ExecutionContext` via `getRequestExecutionContext()` from the ALS
  • Remove duplicate `ExecutionContext` interface definitions in `isr-cache.ts` and `kv-cache-handler.ts`; use the canonical `ExecutionContextLike` from `shims/request-context.ts`
  • Update `isr-cache.test.ts` to supply `ctx` via `runWithExecutionContext()` (ALS) instead of as a direct argument
  • Update `entry-templates.test.ts` snapshots

Files changed

File Change
`server/isr-cache.ts` Drop `ctx?` param from `triggerBackgroundRegeneration()`; remove duplicate interface
`entries/app-rsc-entry.ts` Drop `ctx` 4th param from generated `_handleRequest`; replace `ctx.waitUntil()` with `_getRequestExecutionContext()?.waitUntil()`
`cloudflare/kv-cache-handler.ts` Remove duplicate `ExecutionContext` interface; use `ExecutionContextLike`
`tests/isr-cache.test.ts` Update `ctx.waitUntil` test to use ALS
`tests/snapshots/entry-templates.test.ts.snap` Regenerated (6 snapshots updated)

Remove ctx as an explicit parameter from internal functions so that all
downstream code consistently retrieves the Workers ExecutionContext via
getRequestExecutionContext() from the ALS. Changes:

- isr-cache.ts: drop ctx? param from triggerBackgroundRegeneration();
  remove duplicate ExecutionContext interface (use ALS directly)
- app-rsc-entry.ts: drop ctx 4th param from generated _handleRequest;
  replace ctx.waitUntil() calls with _getRequestExecutionContext()?.waitUntil()
- kv-cache-handler.ts: remove duplicate ExecutionContext interface;
  import ExecutionContextLike from request-context instead
- isr-cache.test.ts: update ctx.waitUntil test to supply ctx via
  runWithExecutionContext() (ALS) instead of as a direct argument
- Update entry-templates.test.ts snapshots
@pkg-pr-new
Copy link
Copy Markdown

pkg-pr-new Bot commented Mar 11, 2026

Open in StackBlitz

npm i https://pkg.pr.new/vinext@431

commit: f101ed0

@github-actions
Copy link
Copy Markdown

Example Preview Production Original
app-router-cloudflare preview production
pages-router-cloudflare preview production
app-router-playground preview production original
realworld-api-rest preview production
nextra-docs-template preview production
benchmarks preview production
hackernews preview production original

@james-elicx
Copy link
Copy Markdown
Collaborator Author

/bigbonk review

Copy link
Copy Markdown
Contributor

@ask-bonk ask-bonk Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean refactoring. The change is straightforward and correct — all ctx parameter threading was already redundant since runWithExecutionContext(ctx, _run) wraps the entire request at the top of handler() (line 1440 in app-rsc-entry.ts), so getRequestExecutionContext() is always populated by the time any waitUntil call runs.

Verified:

  1. ALS is always populated when needed. The outer handler(request, ctx) calls _runWithExecutionContext(ctx, _run) before any code path that reaches _getRequestExecutionContext()?.waitUntil(...). The ?. optional chaining correctly handles Node.js dev where ctx is undefined.

  2. Dev/prod parity is fine. Checked pages-server-entry.ts and dev-server.ts — both already use the ALS pattern (_getRequestExecutionContext() in the inlined triggerBackgroundRegeneration). The dev-server.ts imports triggerBackgroundRegeneration from isr-cache.ts, so it picks up this change automatically. prod-server.ts doesn't use waitUntil directly.

  3. KVCacheHandler retains the constructor fallback. The this.ctx field still exists as a fallback in _deleteInBackground and _put (getRequestExecutionContext() ?? this.ctx), which is the right call — it preserves backward compatibility for anyone constructing KVCacheHandler with an explicit ctx option outside the ALS scope.

  4. Test coverage is adequate. The ALS test wraps triggerBackgroundRegeneration in runWithExecutionContext and asserts waitUntil is called. The "no ctx" test verifies the graceful no-op path.

  5. Snapshot changes are mechanical — just the parameter removal and waitUntil pattern change, repeated across 6 test fixture snapshots. Verified they match the source template changes.

@ask-bonk
Copy link
Copy Markdown
Contributor

ask-bonk Bot commented Mar 11, 2026

Review submitted. I approved PR #431 with a detailed review covering:

  • Correctness: The ALS is always populated before any waitUntil call because _runWithExecutionContext(ctx, _run) wraps the entire request at the handler entry point. Optional chaining (?.) correctly handles Node.js dev where no execution context exists.
  • Dev/prod parity: pages-server-entry.ts and dev-server.ts already use the ALS pattern. dev-server.ts imports from isr-cache.ts so it picks up the change automatically.
  • Backward compatibility: KVCacheHandler retains the constructor ctx fallback (getRequestExecutionContext() ?? this.ctx).
  • Test coverage: Both the ALS path and the no-context graceful path are tested.
  • Snapshots: Mechanical changes matching the source template updates.

All 25 CI checks pass.

github run

@james-elicx james-elicx marked this pull request as ready for review March 11, 2026 07:40
@james-elicx james-elicx merged commit a08a2b5 into main Mar 11, 2026
26 checks passed
@james-elicx james-elicx deleted the refactor/execution-context-als-cleanup branch March 11, 2026 07:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant