You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 3f8ed8b
Browse filesBrowse the repository at this point in the historyBrowse files
fix(redis-worker,run-engine): close the remaining ways a batch item is stranded or run twice
Releasing a slot could silently do nothing. The release pipeline never inspected
its per-command errors, and ioredis resolves a pipeline whose commands failed, so
a failed SREM reported success and the caller went on to destroy the in-flight
record. Release now throws on a failed command.
Reclaim then acted on that false success: it released per message, swallowed any
error, and requeued regardless, which is exactly how a slot ends up held with the
message gone. It now frees the whole timed-out batch in one pipeline before any of
them is requeued, and a failure aborts the requeue so the messages stay in-flight
for the next tick. That also restores the single round trip per shard.
Requeuing removed the message from in-flight before writing it back to the queue.
Redis does not roll back a script that fails partway, so a failed queue write lost
the message outright. The order is now write-then-remove.
Batch items were never heartbeated, so any item slower than the visibility timeout
was reclaimed and handed to a second consumer while the first was still running it,
executing the item twice. Items are now heartbeated for as long as their callback
runs, and the visibility timeout is configurable so this is testable.
0 commit comments