fix(v3): remove executing tasks waiting to deploy - #4432
Conversation
🦋 Changeset detectedLatest commit: 634ec91 The changes in this PR will be included in the next version bump. This PR includes changesets to release 27 packages
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 |
|
Hi @deepshekhardas, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details. |
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (6)
WalkthroughRemoved ✨ Finishing Touches 💡 1⚔️ Resolve merge conflicts 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| "v3.executeTasksWaitingForDeploy": async ({ payload }) => { | ||
| const service = new ExecuteTasksWaitingForDeployService(); | ||
| await service.call(payload.backgroundWorkerId); | ||
| }, |
There was a problem hiding this comment.
🔴 Runs held back until a deploy exists are never started again
The step that releases runs waiting on a deployment has been emptied out ("v3.executeTasksWaitingForDeploy" handler at apps/webapp/app/v3/commonWorker.server.ts:253-254) while runs are still being put into that waiting state, so those runs sit there forever and never execute.
Impact: On legacy-engine projects, any run triggered before its task was deployed stays stuck in "waiting for deploy" indefinitely, even after a successful deploy or promotion.
How waiting runs lose their only drain path
apps/webapp/app/v3/marqs/sharedQueueConsumer.server.ts:1435-1446 still transitions runs to WAITING_FOR_DEPLOY. Previously, ExecuteTasksWaitingForDeployService flipped those runs back to PENDING and re-enqueued them in MarQS, and it was triggered from three places:
- deploy completion (
ExecuteTasksWaitingForDeployService.enqueue(backgroundWorker.id)removed atapps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.ts:211), - promotion/rollback (removed at
apps/webapp/app/v3/services/changeCurrentDeployment.server.ts:176), - the worker jobs in
commonWorker.server.ts/apps/webapp/app/services/worker.server.ts:218-223.
This PR deletes the service file and empties all three, so nothing transitions WAITING_FOR_DEPLOY runs out of that state. Any jobs already enqueued in Redis for v3.executeTasksWaitingForDeploy also become no-ops.
Prompt for agents
The PR deletes apps/webapp/app/v3/services/executeTasksWaitingForDeploy.ts and empties the v3.executeTasksWaitingForDeploy handlers in commonWorker.server.ts and services/worker.server.ts, and removes the enqueue calls in createDeploymentBackgroundWorkerV3.server.ts and changeCurrentDeployment.server.ts. However SharedQueueConsumer (#markRunAsWaitingForDeploy in apps/webapp/app/v3/marqs/sharedQueueConsumer.server.ts) still sets legacy V1 runs to WAITING_FOR_DEPLOY, and no other code transitions them out. Either restore the drain service and its enqueue call sites, or remove the code path that puts runs into WAITING_FOR_DEPLOY in the first place so no run can become permanently stuck.
Was this helpful? React with 👍 or 👎 to provide feedback.
| --- | ||
| "@trigger.dev/core": patch | ||
| --- | ||
|
|
||
| fix(v3): remove executing tasks waiting to deploy | ||
|
|
||
| Removes the executing tasks that are waiting to deploy from the task list. This fixes an issue where tasks in EXECUTING state but waiting for deployment were incorrectly displayed. |
There was a problem hiding this comment.
🟡 Release-notes entry claims a published package changed when only server code did
A changeset targeting the published core package was added ("@trigger.dev/core": patch in .changeset/fix-v3-executing-tasks.md:2) even though the PR only touches server code, so an unrelated package gets a version bump and a misleading release note.
Impact: Users see a package release describing a change that isn't in that package, and the note is written in internal implementation terms rather than user-facing behaviour.
Repository rule for server-only changes
AGENTS.md and CONTRIBUTING.md state: when modifying only server components (apps/webapp/, apps/supervisor/, etc.) with no package changes, add a .server-changes/ file (with area/type frontmatter) instead of a changeset. They also require the description be written for users, not maintainers, and never name internal tooling/infra — the current text ("fix(v3): remove executing tasks waiting to deploy", "tasks in EXECUTING state but waiting for deployment") is implementation-oriented and inaccurate.
Prompt for agents
This PR changes only apps/webapp. Per AGENTS.md and CONTRIBUTING.md, delete .changeset/fix-v3-executing-tasks.md and add a .server-changes/ markdown file instead, with frontmatter `area: webapp` and `type: fix`, and a single plain user-facing sentence describing the behaviour change (no internal service names).
Was this helpful? React with 👍 or 👎 to provide feedback.
| priority: 0, | ||
| maxAttempts: 3, | ||
| handler: async (payload, job) => {}, // This is now handled by redisWorker | ||
| handler: async (payload, job) => { }, // This is now handled by redisWorker |
There was a problem hiding this comment.
🟡 Formatting change would fail the automated code-quality check
An empty function body was reformatted with a space inside the braces (async (payload, job) => { } at apps/webapp/app/services/worker.server.ts:287), which the repository's auto-formatter would rewrite, so the CI formatting check fails.
Impact: The pull request cannot pass CI until formatting is re-run.
Rule reference
AGENTS.md / CONTRIBUTING.md require running pnpm run format (oxfmt) before pushing; the code-quality CI check fails if it produces a diff. The unrelated whitespace change from {} to { } reverts formatter output.
| handler: async (payload, job) => { }, // This is now handled by redisWorker | |
| handler: async (payload, job) => {}, // This is now handled by redisWorker |
Was this helpful? React with 👍 or 👎 to provide feedback.
Removes deprecated ExecuteTasksWaitingForDeployService.