Repository navigation
fix(registry): continue the tail from the last stored release - #160
Merged
Merged
Conversation
fix(repository): map a release offset onto the page size the server serves A release deleted upstream below the checked span, or a vanished draft placeholder, shifted the listing and `extend()` skipped a release for good; with offset paging the position can only be confirmed by finding the last stored release. Within the TTL the record is trusted whole, like its head, so the confirmation costs a request only after a check and only on a page boundary. The sources assumed 100 releases per page; the real size is learned from a page followed by another one rather than stored, to keep provider paging out of the record format. Closes #159 Assisted-By: Claude Fable 5.1 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests.
... and 9 files with indirect coverage changes 🚀 New features to boost your workflow:
|
refactor(repository): share the paged release source between providers A check that failed or bailed out has nothing to compare the stored list against, so the tail is taken as it is: a confirmation there would spend a request where a rate limit just refused one, and a tail dropped before its reload could fail left an empty record behind. The dropped tail is now written only along with the first page that replaces it. A source that answers the anchor position with no page at all has shifted too; taking it for a complete listing kept losing the release. The page size is learned from the first page only, the one page whose start is known: a shorter page further down is a release filtered out after paging, and taking it for the page size dropped releases within the TTL. Assisted-By: Claude Fable 5.1 <noreply@anthropic.com>
fix(repository): count unreadable releases among the skipped positions refactor(repository): own the paged release source A check that failed or bailed out on an unreadable release compared nothing, so taking the tail as confirmed let a deletion below the head lose a release for good; the confirmation lies on the page the tail needs anyway, and a dropped tail is written only with its replacement, so skipping it spared nothing. An unreadable release holds a listing position but is missing from a page's list, so the check reports such positions for the anchor, and the source no longer drops a readable release behind them when it skips into a page. The registry knows nothing of pages, so the paged source belongs to the repository module; its page size is learned per instance, which rules out servers serving more releases per page than asked for, as GitHub and GitLab never do. Assisted-By: Claude Fable 5.1 <noreply@anthropic.com>
…ext one A release the record does not hold above the stored tail, an unreadable one or one published while the check could not store it, moves the last stored release down the listing, so expecting it exactly at the stored count took every such release for a deletion and reloaded the tail on every check. The count of unreadable releases the check saw could not tell those apart from a stored release that turned unreadable, so the position is searched for instead of computed. A shift down is bounded by what lies above the tail, less than a page in practice, while a shift up has no bound, so one further page is the place to look before giving the tail up. Assisted-By: Claude Fable 5.1 <noreply@anthropic.com>
fix(repository): take a first page for the page size only when it holds at most half The page holding the last stored position shows which way the listing moved, so the tail continues after the last stored release found there; dropping and reloading the unverified tail cost a request per stored page, and a release deleted upstream stays stored until its download fails and it is forgotten. Within the TTL the tail is located the same way: trusting it whole lost a release deleted in that window for good. A first page short of a release or two is one filtered out after paging; taking it for the page size made every check reload the tail. Assisted-By: Claude Opus 5.5 <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.
🔍 What was changed
How it works
Review notes
Link rel=next) shifts the same way, and neither GitHub nor GitLab offers keyset pagination for releases.ReleaseSource::pages($offset)now yields whole pages carrying the listing position of their first release, starting with the page that holds$offset.Checklist