fix(background-tasks-server): make background tasks run on the server flavour#5420
Closed
adrians5j wants to merge 1 commit into
Closed
fix(background-tasks-server): make background tasks run on the server flavour#5420adrians5j wants to merge 1 commit into
adrians5j wants to merge 1 commit into
Conversation
adrians5j
force-pushed
the
adrian/self-hosted-bg-task-worker-path
branch
2 times, most recently
from
July 16, 2026 09:40
aa48b5b to
6502841
Compare
… flavour
Two issues left every server-flavour background task stuck "pending" (worker never completed):
1. Worker asset path. The worker was spawned via
`new Worker(new URL("../worker/workerEntry.js", import.meta.url))`. The app bundler rewrites that
`new URL` to a publicPath-based asset ("/static/assets/workerEntry.<hash>.js") that `new Worker()`
can't load as a filesystem path. `import.meta.url` resolves to this module inside its own dist (the
bundler preserves it, doesn't inline the package), and the compiled worker + deps live beside it
under dist/worker with only relative/node-builtin imports — so resolve it with `path.join` off
`import.meta.url` (which the bundler leaves untouched), pointing at the real dist worker.
2. Task-event validation. The shared TaskRunner's TaskEventValidation requires AWS Step Functions
fields (endpoint / executionName / stateMachineId). AWS's Lambda passes them from the SFN execution
context; the server worker's event didn't have them, so every task failed validation. Supply them
from the worker: executionName = the task id (a stable run id the runner uses for log entries);
endpoint / stateMachineId are validate-only off-AWS.
Also surface the worker's error (previously discarded) so a failed task logs instead of silently
staying "pending". Verified end-to-end on the server flavour: image upload → worker spawns, POSTs the
background-task route, and the tasks run to completion. AWS flavour unaffected (uses StepFunctionService).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
adrians5j
force-pushed
the
adrian/self-hosted-bg-task-worker-path
branch
from
July 16, 2026 10:29
6502841 to
f557f54
Compare
adrians5j
changed the title
Member
Author
|
Folded into #5414 (collapsed the server-flavour follow-ups into a single PR). |
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
1 participant
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.
Every background task on the self-hosted (server) flavour stayed stuck
pending— the worker never completed. Two root causes, both confirmed via runtime logging:1. Worker asset path
WorkerServicespawned the worker vianew Worker(new URL("../worker/workerEntry.js", import.meta.url)). The app bundler rewrites thatnew URL(...)to a publicPath asset (/static/assets/workerEntry.<hash>.js), whichnew Worker()then can't load as a filesystem path →Cannot find module '/static/assets/...'.import.meta.urlresolves to this module inside its own dist (the bundler preserves it and doesn't inline the package), and the compiled worker + deps live beside it underdist/worker/(relative + node-builtin imports only). So resolve it withpath.joinoffimport.meta.url— an expression the bundler leaves untouched — pointing at the real dist worker.2. Task-event validation (AWS leak in the shared runner)
Past the worker, the shared
TaskRunner'sTaskEventValidationrequires AWS Step Functions fields —endpoint,executionName,stateMachineId:AWS's Lambda passes them from the SFN execution context; the server worker's event didn't. Supply them from the server transport:
executionName= the task id (a stable run id the runner uses for log entries);endpoint/stateMachineIdare validate-only off-AWS.Also surfaces the worker's error (previously discarded) so a failed task logs instead of silently staying
pending.Verified
End-to-end on the server flavour: image upload → worker spawns → POSTs
/background-task→ validation passes → task runs to completion, AI SDK invoked. AWS flavour unaffected (usesStepFunctionService, not this worker).🤖 Generated with Claude Code