Fold a mid-run refresh into the run instead of re-enqueueing it - #828
Merged
Merged
Conversation
Merge staging into main: mobile layout setting
Brings staging up to main's tip so the release PR can merge (#827).
The follow-up refresh #813 promises never ran. runPendingRefresh called enqueueSource from inside the processor, where BullMQ still holds ParseSource-<id> as active -- so enqueueSource took its own active branch and wrote the pending marker straight back instead of queueing anything. The marker ping-ponged and the content still waited for the next poll, which for a verified websub source is up to a day: the exact symptom the issue is about. The unit test could not see it, stubbing enqueueSource out entirely. The id cannot be free until the processor returns, so the run answers the requests itself: take the marker, parse once more with the flags they asked for. A deferral or a failure leaves the marker for the next run, as before. This also drops a dead branch -- parseSource only rethrows HttpDeferredError, so the non-deferred catch never ran. Also: the re-registration path stored its fresh activation token after mailing it, so a failed write mailed a token the row never took and put the address back in the dead end #810 fixes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two fixes found reviewing #827, plus main's tip merged in so #827 can merge.
The #813 follow-up refresh never ran
runPendingRefreshcalledenqueueSourcefrom inside the processor. Atthat point BullMQ still holds
ParseSource-<id>asactive, soenqueueSourcetook its ownactivebranch and wrote the pending markerstraight back instead of queueing anything. The marker ping-ponged
between take and re-write, and the content still waited for the next poll
-- for a verified websub source, up to a day. That is the exact symptom
the issue is about.
The comment claimed "the job's id is free by the time this runs", which
is not true inside the processor: the id is released when the processor
returns. So the run answers the requests itself -- take the marker, parse
once more with the flags they asked for. A deferral or a failure leaves
the marker for the next run, as before.
The unit test stubbed
enqueueSourceout entirely, so it could not seethis. It now pins the two parses and asserts the enqueuer is not called.
This also drops a dead branch:
parseSourceonly rethrowsHttpDeferredError, so the non-deferredcatchnever ran.Re-registration mailed a token it had not stored yet
The #810 recovery path awaited
sendActivationEmailbeforerefreshActivationToken. A failed write mailed a token the row nevertook, putting the address back in the dead end it just asked to leave,
one throttle slot poorer. Write first.
🤖 Generated with Claude Code