Trigger.dev version skew protection and in-flight Sume jobs

With Trigger.dev's Version Skew Protection, a run stays on the deployment built from the same commit, so a deploy mid-run does not change the code that finishes your Sume task. The September 23, 2026 changelog says it pins every run to that deployment. That helps a task that created a Sume job and is waiting for it, but the job itself lives at Sume, so its id is what survives anything.

What gets pinned and what does not

Failure the pin prevents

Imagine a task that submits a create call with body shape A, waits, then reads the result expecting shape A. A deploy changes the body shape to B. A resumed run on new code would reuse the same key with a different body and get 409 idempotency_conflict. With pinning, the old run keeps old code, so create and read stay consistent.

New runs use new code. If the key included a code version and you want a clean break, give the new version a new key.

What to store before you wait

Persist the Sume job id as soon as the create call returns 202. Then if a run is cancelled, retried or restarted, the next attempt can read GET /v1/jobs/:id/status instead of creating another job.

• Cancelling a Trigger.dev run does not stop Sume generation. Use POST /v1/jobs/:id/cancel, which returns 409 job_generation_already_started once generation has begun.
• A client timeout leaves the job running and billing.
• Prefer webhook mode with job.completed over holding a task open.

Waiting well

Use Sume's next_poll_after_seconds for the poll interval, and use waitForJob from @sume-com/sdk if you are in TypeScript. Verify webhooks with the SDK's async verifyWebhook. Either way, end with a terminal status check rather than assuming success.