fix: recover timestamp-only legacy claims - #313
Conversation
5248f3c to
5f18dee
Compare
ad8cf59 to
7b7dc99
Compare
c1d3961
into
codex/pr198-f4-task-event-publisher-reuse
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7b7dc990b7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| local timestamp = legacy_marker_timestamp(current_marker, now_ms) | ||
| if not timestamp then | ||
| error('forge_queue_claim_marker_invalid') |
There was a problem hiding this comment.
Preserve nonce-bearing legacy claim markers
When an upgrade leaves an in-flight raw job claimed by the queue implementation introduced in 7245157, its claim hash contains the valid historical timestamp:UUID marker. The previous valid_marker path recovered that job, but legacy_marker_timestamp now rejects it, causing every recovery sweep to report Queue legacy occurrence recovery failed while the job remains permanently stranded in the processing list. Accept both strictly validated historical marker formats and extract the timestamp from either.
Useful? React with 👍 / 👎.
Source Issue
Issue: #179
What changed
The legacy processing-list recovery branch now accepts the one historic claim shape: a positive Redis-authored timestamp with no suffix. It validates that timestamp strictly, uses it to decide freshness, and requeues stale legacy work through the existing atomic conversion.
Current occurrence envelopes still require the full
timestamp:UUIDmarker. This closes PR #198 findingPRRT_kwDOS9dWe86VJqj2without broadening current ownership parsing.Safety boundary
Base and scope
codex/pr198-f4-task-event-publisher-reuse5f18dee092c956f84c2a6b97767e89d2dea542717b7dc990b7c1c1e90cb627011ade259ab5bc4957Validation
git diff --check: passed30560042976, job90930397454: passed with 1,754/1,754 units, 16/16 S4 PostgreSQL, Redis 3/3, Redis ACL 3/3, cross-sink 1/1, S3 16/16, ingress 1/1, and E2E 17 passed30560043412, job90930399038: passedStack
This is the top draft child. The required progressive merge order is F5 → F4 → F3 → #310 → #309 → #198.