Add changeset for v3 executing tasks fix - #4462
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. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
🟡 Formatting change will fail the automated code-quality check
An empty function body is rewritten with a space inside the braces (async (payload, job) => { } at apps/webapp/app/services/worker.server.ts:291), which the repository's auto-formatter will rewrite, so the required formatting check fails.
Impact: The pull request's CI code-quality job fails until the formatting is reverted.
Rule reference
AGENTS.md ("Formatting and linting") states format/lint are enforced by CI (code-quality check) and CONTRIBUTING.md requires running pnpm run format before pushing; oxfmt normalizes empty blocks to {} (as they were before this diff).
(Refers to line 291)
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 note added to the wrong product, publishing an npm package with an unrelated note
A note for a change that only touches the server app is filed against the published @trigger.dev/core package ("@trigger.dev/core": patch at .changeset/fix-v3-executing-tasks.md:2) instead of the server-changes folder, so a package release is cut with a changelog entry describing work that never happened in that package.
Impact: Users see a version bump and release note for a package that did not change, and the actual server change is missing from server release notes.
Repository rule: changesets are only for packages/*, server-only changes use .server-changes/
AGENTS.md ("Changesets and Server Changes") and CONTRIBUTING.md ("Adding server changes") state: "When modifying only server components (apps/webapp/, apps/supervisor/, etc.) with no package changes, add a .server-changes/ file instead." All code in this PR is under apps/webapp/ (apps/webapp/app/services/worker.server.ts, apps/webapp/app/v3/commonWorker.server.ts, apps/webapp/app/v3/services/changeCurrentDeployment.server.ts, apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.ts, and the deleted apps/webapp/app/v3/services/executeTasksWaitingForDeploy.ts); no file under packages/ is touched.
Additionally the body violates "Write the description for users, not maintainers" — fix(v3): remove executing tasks waiting to deploy is a commit-style, implementation-named line, and the second paragraph describes internal run states (EXECUTING, deployment waiting) rather than user-visible behavior.
Prompt for agents
This PR only changes files under apps/webapp/, so per AGENTS.md and CONTRIBUTING.md it must not add a changeset for a published package. Delete .changeset/fix-v3-executing-tasks.md and instead add a .server-changes/ markdown file with frontmatter `area: webapp` and `type: fix` (see .server-changes/README.md), with a one-line, user-facing description that avoids internal tool/state names and describes the behavior change for users.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
|
||
| // Only V1 engine workers need the WAITING_FOR_DEPLOY drain — V2 runs sit | ||
| // in PENDING_VERSION and are handled out of band, so enqueuing here for V2 | ||
| // just produces empty scans of the TaskRun status index. | ||
| const worker = await this._prisma.backgroundWorker.findFirst({ | ||
| where: { id: deployment.workerId }, | ||
| select: { engine: true }, | ||
| }); | ||
|
|
||
| if (worker?.engine === "V1") { | ||
| await ExecuteTasksWaitingForDeployService.enqueue(deployment.workerId); | ||
| } | ||
| } |
There was a problem hiding this comment.
🔍 Legacy V1 runs can still enter WAITING_FOR_DEPLOY with no drain left
The V1 shared queue consumer still transitions runs into WAITING_FOR_DEPLOY (apps/webapp/app/v3/marqs/sharedQueueConsumer.server.ts:1433-1444). With the drain service deleted and both enqueue sites removed (here and in apps/webapp/app/v3/services/createDeploymentBackgroundWorkerV3.server.ts:212), nothing in the webapp flips those runs back to PENDING or re-enqueues them into MarQS, so any V1 run parked in that state would stay there indefinitely. Worth confirming that no V1 engine environments remain that can still hit the shared queue consumer path, otherwise the consumer-side marking should be removed/failed-fast too.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
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 |
1 participant
Chore changeset for the deprecated executeTasksWaitingForDeploy cleanup. See original #3310.