Skip to content

Commit 4f6cee2

Browse files
committed
fix(run-engine): keep the ck vtime floor alive alongside the tags it scores
The gated-registration path in the vtime dequeue was the one writer that touched :ckVtime without also touching :ckVtimeFloor. Everything else keeps the pair alive together: the enqueue and nack registrations EXPIRE both, and a serving dequeue SETs the floor with its own TTL. That path runs on calls that serve nothing, so the floor-persist block, which is guarded on having served, is skipped. A base queue whose variants are all sat at their per-key ceiling therefore refreshes the tags on every poll while the floor's TTL runs down underneath them. Once it expires the next registration reads GET ckVtimeFloorKey back as '0' and starts a brand-new variant below every established tag, so it leads pass 1 until it catches up. Same hole as the one the enqueue floor-TTL test was added to close, reached by a different path. Reported by Devin on #4367.
1 parent 845c792 commit 4f6cee2

1 file changed

Lines changed: 7 additions & 0 deletions

File tree

  • internal-packages/run-engine/src/run-queue

internal-packages/run-engine/src/run-queue/index.ts

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5621,6 +5621,13 @@ if gatedPending ~= nil then
56215621
end
56225622
end
56235623
redis.call('EXPIRE', ckVtimeKey, stateTtl)
5624+
-- This is the one write path that touches ckVtime without going through the
5625+
-- floor-persist block below, which only runs when the call served something. Left
5626+
-- alone, a queue whose variants are all gated refreshes ckVtime's TTL here on every
5627+
-- poll while the floor's runs down, and once the floor expires out from under a live
5628+
-- ckVtime the next registration reads it back as 0 and starts a brand-new variant
5629+
-- below every established tag.
5630+
redis.call('SET', ckVtimeFloorKey, tostring(floor), 'EX', stateTtl)
56245631
end
56255632
end
56265633

0 commit comments

Comments
 (0)