Keep the task host out of the edge bundle - #72
Merged
Merged
Conversation
Next builds `instrumentation.ts` for every runtime it has, and this app has an edge one because `proxy.ts` is middleware. The edge build followed the top-level import into `src/task-host.ts`, found `process.exit` and `process.once`, and failed to compile. Turbopack retried it on the next request and the one after that: about seventy failed compiles per page in `next dev`, each printing its stack, none of them for code the edge runtime was ever going to call. On the macos CI runner that cost is charged to whichever expectation is waiting for a route to finish compiling. It is how `ux-shell.spec.ts` spent 95 seconds waiting for `/quotes` on the run that went red, and then its whole 120-second budget, taking the command-palette test and 25 unrun tests with it. The same shard was green on the commit before at 60 seconds for that test, so this had been marginal since the runtime landed rather than broken outright. The hook now declines the edge runtime by name and loads the host through a dynamic import, because a top-level import puts the module in the edge bundle whatever the guard decides at runtime. Excluding edge rather than requiring node is deliberate, and `src/task-host.ts` records why at its own guard: the standalone server can reach a runtime check with `NEXT_RUNTIME` unset, and a host that starts nowhere neither drains the queue nor handles SIGTERM. Measured on a cleared dev cache, three page loads: 268 failed edge compiles before, 0 after. A production build with `CLOCKWORK_TASK_RUNTIME=sqs` still reaches the poller, failing only on this machine's missing database URL. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RzTEVpxi5LHTXSZywnFjea
hannahhoward
requested review from
alanshaw,
bajtos,
jameskurz-filecoin and
relotnek
as code owners
September 21, 2026 03:20
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
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.
Summary
apps/web/instrumentation.tsdeclines the edge runtime by name and loads the task host through a dynamic import, sosrc/task-host.tsnever enters the edge bundle.Next builds
instrumentation.tsfor every runtime it has, and this app has an edge one becauseproxy.tsis middleware. The edge build followed the top-level import intosrc/task-host.ts, foundprocess.exitandprocess.once, and failed to compile. Turbopack retried it on the next request and the one after: about seventy failed compiles per page innext dev, each printing its stack, none of them for code the edge runtime was ever going to call.On the macos CI runner that cost lands on whichever expectation is waiting for a route to finish compiling. That is how run 35555556886 went red:
ux-shell.spec.tswaited 95 seconds for/quotes, spent its whole 120-second budget, and took the command-palette test and 25 unrun tests with it. The same shard was green on the commit before at 60 seconds for that test, so this had been marginal since #60 landed rather than broken outright. The red run's own change was Terraform only.Excluding edge rather than requiring node is deliberate, and
src/task-host.tsrecords why at its own guard: the standalone server can reach a runtime check withNEXT_RUNTIMEunset, and a host that starts nowhere neither drains the queue nor handles SIGTERM. Unset starts the host; only the literal"edge"declines.Deliverables
apps/web/instrumentation.tsTest plan
next buildthenpnpm startwithCLOCKWORK_TASK_RUNTIME=sqsstill reaches the poller, failing only on this machine's missingCLOCKWORK_SERVICE_DATABASE_URLux-shell.spec.ts15/15 locally, including both tests that failed on CIsrc/task-host.test.ts8/8uishard goes green on CI: 113/113, with the drawer test at 31.1s against 122.9s on the red run and 60.3s on the last green one🤖 Generated with Claude Code
https://claude.ai/code/session_01RzTEVpxi5LHTXSZywnFjea