Why do you want to contribute?
I'd like to fix #3726 — ExponentialBackoff.execute() never counts callback wall-clock time toward maxElapsed, so a slow callback can run well past the intended deadline. This is exactly the open question flagged in the // TODO at packages/core/src/v3/apps/backoff.ts:101 ("With .execute(), should this also include the time it takes to execute the callback?").
I already have a failing regression test reproducing the bug and a minimal fix ready, and would open it as a single-issue PR once vouched.
Prior contributions or relevant experience
I build event-driven durable-execution infrastructure. My project ykstorm/anvil is an idempotent webhook → BullMQ worker pipeline: HMAC-verified ingestion with idempotency keys, retry, and dead-letter handling (measured constant-time HMAC verification, real end-to-end test suite). Trigger.dev's retry/backoff internals are directly in my wheelhouse.
Scope discipline: single-issue PR, minimal diff, changeset included, no unrelated refactors.
Why do you want to contribute?
I'd like to fix #3726 —
ExponentialBackoff.execute()never counts callback wall-clock time towardmaxElapsed, so a slow callback can run well past the intended deadline. This is exactly the open question flagged in the// TODOatpackages/core/src/v3/apps/backoff.ts:101("With .execute(), should this also include the time it takes to execute the callback?").I already have a failing regression test reproducing the bug and a minimal fix ready, and would open it as a single-issue PR once vouched.
Prior contributions or relevant experience
I build event-driven durable-execution infrastructure. My project ykstorm/anvil is an idempotent webhook → BullMQ worker pipeline: HMAC-verified ingestion with idempotency keys, retry, and dead-letter handling (measured constant-time HMAC verification, real end-to-end test suite). Trigger.dev's retry/backoff internals are directly in my wheelhouse.
Scope discipline: single-issue PR, minimal diff, changeset included, no unrelated refactors.