|
| 1 | +--- |
| 2 | +area: webapp |
| 3 | +type: fix |
| 4 | +--- |
| 5 | + |
| 6 | +Batch items that hit the environment queue size limit now fast-fail without |
| 7 | +retries and without creating pre-failed TaskRuns. |
| 8 | + |
| 9 | +## Why |
| 10 | + |
| 11 | +When a customer fills their environment's queue (default 2.5M) and keeps |
| 12 | +pushing batch triggers, every batch item was hitting `ServiceValidationError` |
| 13 | +from `validateQueueLimits`, looping through 6 exponential-backoff retries |
| 14 | +(~63s per item), and then creating a pre-failed `TaskRun` for each item on the |
| 15 | +final attempt — bringing its attempt, trace events, and a `BatchTaskRunError` |
| 16 | +row along for the ride. |
| 17 | + |
| 18 | +At customer-overload scale (one tenant pushing ~1 batch/s × ~10 items each |
| 19 | +against a paused/full queue) this: |
| 20 | + |
| 21 | +1. filled `redis_alt` with hundreds of thousands of never-completing |
| 22 | + `engine:batch:*` keys, because items kept bouncing between the FairQueue |
| 23 | + and the in-flight hash, |
| 24 | +2. pinned the batch worker on doomed retries instead of processing healthy |
| 25 | + batches, and |
| 26 | +3. created enormous volumes of pre-failed `TaskRun` / `BatchTaskRunError` |
| 27 | + rows that serve no customer purpose (the items were never going to |
| 28 | + trigger — the customer just needs to fix their queue). |
| 29 | + |
| 30 | +## What changed |
| 31 | + |
| 32 | +- New `QueueSizeLimitExceededError` subclass of `ServiceValidationError` — |
| 33 | + thrown by `runEngine/services/triggerTask.server.ts` instead of the generic |
| 34 | + validation error, so callers can detect this specific overload condition. |
| 35 | +- `ProcessBatchItemCallback` result gains an optional `skipRetries?: boolean` |
| 36 | + flag. When true, the `BatchQueue` records the failure immediately regardless |
| 37 | + of attempt number, bypassing the FairQueue retry ladder. |
| 38 | +- The batch process-item callback in `runEngineHandlers.server.ts` detects |
| 39 | + `QueueSizeLimitExceededError` and returns |
| 40 | + `{ success: false, errorCode: "QUEUE_SIZE_LIMIT_EXCEEDED", skipRetries: true }` |
| 41 | + **without** calling `triggerFailedTaskService` — no pre-failed TaskRun is |
| 42 | + created for these items. |
| 43 | +- The batch completion callback collapses per-item `BatchTaskRunError` writes |
| 44 | + into a single aggregate row when every failure shares the same |
| 45 | + `QUEUE_SIZE_LIMIT_EXCEEDED` error code, bounding DB writes to O(batches) |
| 46 | + instead of O(items) during overload events. |
| 47 | + |
| 48 | +Other error types (transient trigger failures, environment not found, etc.) |
| 49 | +retain the existing retry + pre-failed-run behavior. |
| 50 | + |
| 51 | +## Test plan |
| 52 | + |
| 53 | +### Unit tests |
| 54 | + |
| 55 | +New `skipRetries on failed items` suite in |
| 56 | +`internal-packages/run-engine/src/batch-queue/tests/index.test.ts`: |
| 57 | + |
| 58 | +```bash |
| 59 | +cd internal-packages/run-engine |
| 60 | +pnpm run test ./src/batch-queue/tests/index.test.ts --run |
| 61 | +``` |
| 62 | + |
| 63 | +Covers: |
| 64 | + |
| 65 | +- `skipRetries: true` from the callback → item called exactly once, not |
| 66 | + `maxAttempts` times. |
| 67 | +- Regression guard: when `skipRetries` is not set, the retry ladder still |
| 68 | + fires (items called `maxAttempts` times). |
| 69 | +- Per-item mixing within one batch: even-indexed items fast-fail, odd-indexed |
| 70 | + items exhaust the retry ladder — all correctly tracked. |
| 71 | + |
| 72 | +### Manual e2e (local, against `references/hello-world`) |
| 73 | + |
| 74 | +Done before merge — reproduces the Centralize-style overload against the |
| 75 | +local dev stack. |
| 76 | + |
| 77 | +Setup: |
| 78 | + |
| 79 | +1. Add `MAXIMUM_DEPLOYED_QUEUE_SIZE=2` to the webapp's `.env.local` (or |
| 80 | + whatever file your local webapp reads — this caps the deployed queue at |
| 81 | + just 2 items). |
| 82 | +2. `pnpm run dev --filter webapp` |
| 83 | +3. `cd references/hello-world && pnpm exec trigger dev` |
| 84 | +4. Temporarily add a blocking task to `references/hello-world/src/trigger/`: |
| 85 | + |
| 86 | + ```ts |
| 87 | + export const sleepyTask = task({ |
| 88 | + id: "sleepy-task", |
| 89 | + run: async () => { |
| 90 | + await new Promise((r) => setTimeout(r, 10 * 60 * 1000)); |
| 91 | + }, |
| 92 | + }); |
| 93 | + ``` |
| 94 | + |
| 95 | +5. Trigger `sleepy-task` twice individually via the dashboard or MCP so the |
| 96 | + queue is holding 2 items and hits the cap. |
| 97 | + |
| 98 | +Exercise the fix: |
| 99 | + |
| 100 | +6. Trigger a batch with 5 items of `sleepy-task` via |
| 101 | + `mcp__trigger__trigger_task` (or the batch API directly). |
| 102 | + |
| 103 | +Expected observations (all must be true): |
| 104 | + |
| 105 | +- [ ] Dashboard: the new batch transitions to `ABORTED` within a second or |
| 106 | + two — it does **not** sit in `PROCESSING` for a minute+. |
| 107 | +- [ ] DB: `BatchTaskRun` row has |
| 108 | + `status='ABORTED'`, `failedRunCount=5`, `successfulRunCount=0`. |
| 109 | +- [ ] DB: **exactly one** `BatchTaskRunError` row for the batch |
| 110 | + (`SELECT COUNT(*) FROM "BatchTaskRunError" WHERE "batchTaskRunId"=…`), |
| 111 | + with the error text mentioning `"5 items in this batch failed with |
| 112 | + the same error"` and `errorCode='QUEUE_SIZE_LIMIT_EXCEEDED'`. |
| 113 | +- [ ] DB: **no new `TaskRun` rows** were created for the batch items |
| 114 | + (compare `SELECT COUNT(*) FROM "TaskRun" WHERE "batchId"=…` before |
| 115 | + and after — should stay 0). |
| 116 | +- [ ] Webapp logs: one |
| 117 | + `"[BatchQueue] Batch item rejected: queue size limit reached"` per |
| 118 | + item at `warn` level, **no** |
| 119 | + `"[BatchQueue] Failed to trigger batch item"` error lines, **no** |
| 120 | + `"TriggerFailedTaskService"` log lines for the batch items. |
| 121 | +- [ ] Redis (via `redis-cli` against the local redis instance backing the |
| 122 | + batch queue): `engine:batch:<batchId>:*` keys are gone after the batch |
| 123 | + finalizes, and so are the |
| 124 | + `engine:batch:queue:env:<envId>:batch:<batchId>*` keys. |
| 125 | + |
| 126 | +Clean up: |
| 127 | + |
| 128 | +7. Cancel the two `sleepy-task` runs to unblock the queue. |
| 129 | +8. Remove the temporary `sleepy-task` file and the |
| 130 | + `MAXIMUM_DEPLOYED_QUEUE_SIZE` override. |
0 commit comments