From 7f01aaf2f0696f8cc03ebd4a9557bc427a7634a1 Mon Sep 17 00:00:00 2001 From: Wes Mason Date: Fri, 21 Aug 2026 14:59:37 +0100 Subject: [PATCH] fix(run-engine): re-register the TTL entry when the vtime dequeue expires a run The vtime dequeue is a copy of dequeueMessagesFromCkQueueTracked, and main added a TTL re-registration to that command while this branch was open. A copy cannot pick up a change to its original, so the rebase left the vtime path behind: it drops an expired run from the queue sorted sets and defers to a TTL consumer that has no entry for it, because the entry is removed on first dequeue. The run is then orphaned. Only reachable with the flag on, so nothing shipped, but it would have gone out with the feature. Same four lines as the base command, verbatim; the expired branch is now identical between the two again. Copies drifting like this is a known cost of the vtime scripts being copies, kept deliberately so the flag-off path stays byte-identical to production. The drift is worth a test that pins each copy against its original, which would have caught this the day main merged. --- internal-packages/run-engine/src/run-queue/index.ts | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/internal-packages/run-engine/src/run-queue/index.ts b/internal-packages/run-engine/src/run-queue/index.ts index 47e3f1468..48ac59072 100644 --- a/internal-packages/run-engine/src/run-queue/index.ts +++ b/internal-packages/run-engine/src/run-queue/index.ts @@ -5526,6 +5526,10 @@ local function tryServe(ckQueueName, mayRaiseFloor, knownRegistered) redis.call('ZREM', fullQueueKey, messageId) redis.call('ZREM', envQueueKey, messageId) decrLengthCounter() + if ttlQueueKey and ttlQueueKey ~= '' then + local ttlMember = ckQueueName .. '|' .. messageId .. '|' .. (messageData.orgId or '') + redis.call('ZADD', ttlQueueKey, ttlExpiresAt, ttlMember) + end else redis.call('ZREM', fullQueueKey, messageId) redis.call('ZREM', envQueueKey, messageId)