mirror of
https://github.com/vercel/workflow.git
synced 2026-09-14 19:59:43 +08:00
Pranay Prakash
fb9e27589d
* perf(core): commit pre-claimed inline pairs in their own batch chunk The batched fan-out fold sorted the pre-claimed inline [step_created, step_started] pairs to the front and then filled the same chunk with plain step/wait creates up to MAX_BATCH_FANOUT_EVENTS. Only that chunk gates the inline bodies, so the bodies waited on a 32-row commit (a 61-item DynamoDB transaction on the Vercel backend) when all they needed was the pairs' own rows. Chunk the pair rows and the plain creates separately: the pairs get their own leading chunk(s), still adjacent and never split across a boundary, and the plain creates fill the subsequent chunks of 32, committing concurrently beside the pair chunk and gating only their own queue publishes. Eligibility, the batch-of-one rule, pairCommits gating, per-chunk publishes and the foreign-interleaving diagnostic are unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * perf(core): fold pairs only with two inline steps; guard a lone plain create With the pairs in a chunk of their own, plain creates alongside them share no round trip with the pairs, so "company" no longer makes a lone pair worth folding. `inlinePairFoldEligible` now requires two or more inline steps: a lone inline step keeps the lazy `step_started` (one row, optimistic-start capable, bump-and-report) while the eager creates beside it still batch. A plain partition of exactly one entry is the batch-of-one case again, so it takes the guarded single create (slot-snapshot params, bump-and-report, same conflict tolerance and `createdStepCorrelationIds` bookkeeping) instead of a one-row createBatch, and its queue publish still waits for that create. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>