Skip to content

Only update jobs with a later queued_at timestamp#3

Merged
nyergler merged 1 commit into
masterfrom
enqueue-gt
Mar 15, 2024
Merged

Only update jobs with a later queued_at timestamp#3
nyergler merged 1 commit into
masterfrom
enqueue-gt

Conversation

@nyergler
Copy link
Copy Markdown
Member

No description provided.

@nyergler nyergler requested a review from JakeNeyer March 15, 2024 19:15
@nyergler nyergler merged commit 2e0cbc0 into master Mar 15, 2024
nyergler added a commit that referenced this pull request May 14, 2026
Enqueue and PromoteJob have both used ZADD XX GT since #3 to preserve
the deferral guarantee for jobs enqueued with deterministic IDs: once a
schedule sits at time T in the future, a duplicate enqueue at T' < T
must be a no-op, and PromoteJob must not demote a job whose score has
been bumped to now + InvisibleSec by Dequeue. That is the right
semantic for dedup-style jobs that may race their own re-enqueue.

It is the wrong semantic for two cases that have grown up around the
queue since:

1. Worker retry rescheduling. When a handler returns an error the
   retry middleware computes a backoff delay and calls Enqueue with
   score = now + delay. With GT, that score is rejected because the
   Dequeue invisibility mark (now + InvisibleSec, typically 60s) is
   greater. The configured Backoff is effectively dead for any value
   less than InvisibleSec; gated handlers re-run only on the
   InvisibleSec cadence regardless of how short the backoff is.

2. Subqueue PromoteOnAck. The subqueue middleware advances the next
   gated job after the prior handler Acks by calling PromoteJob on
   that job's ID. With GT, the score (still sitting at the
   InvisibleSec mark from its last dequeue/gated cycle) is also
   rejected and the next job continues to wait out its full
   invisibility window.

Add a per-job AllowPromotion flag. Default false preserves today's GT
semantics so dedup-deferral jobs are unaffected; setting true causes
Enqueue to use plain ZADD XX so backoff can lower the score, and
causes PromoteJob to use ZADD XX (without GT) so the next gated
subqueue entry can be advanced. The flag is read only after the job 
is initially enqueued. 

The Enqueue Lua script splits the per-job arg list into two ZADD
calls (one with gt, one without) so a mixed BulkEnqueue stays atomic.
PromoteJob does an HGET to read the flag before issuing the ZADD;
this adds one round-trip per promotion but keeps the API stable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant