fix(ui): page the conformance self-fetch and never cache an empty registry - #464
Open
angela-helios wants to merge 1 commit into
Open
fix(ui): page the conformance self-fetch and never cache an empty registry#464angela-helios wants to merge 1 commit into
angela-helios wants to merge 1 commit into
Conversation
…istry The self-fetch asked for 10000 in one page and trusted the answer, but a server capping _count at 1000 silently truncated the registry — 1377 R4 SearchParameters served as 1000, and the viewer under-reported without a trace (#460). The fetch now follows next links (rebased onto the loopback base, since the advertised link carries the server's public base URL) and fails the whole fetch if any page fails, because a silently partial registry is the bug this exists to fix. The catalogs also stop caching an *empty success* (#462): storage seeds the conformance resources at startup, so an empty search answer means the backend's index has not caught up (a composite's ES sync), and pinning it kept the pages broken long after the sync landed. Empty is now served for its request only, like a failure already was. Closes #460
Code reviewNo issues found. Checked for bugs and CLAUDE.md compliance. |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
9 tasks
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
2 participants
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.
Closes #460
Two robustness fixes to the UI's conformance self-fetch, both found by the #448 sweep and the #449 matrix validation:
Paging (#460). The fetch asked for
_count=10000in one page and trusted the answer — but the server caps_countat 1000, so the R4 registry (1,377 SearchParameters) was silently served as 1,000 and the viewer under-reported with no trace. The fetch now followsnextlinks (rebased onto the loopback base, since advertised links carry the server's public base URL) and fails the whole fetch if any page fails — a silently partial registry is precisely the bug.Empty is not cached (#462, UI facet). The catalogs cached any successful fetch for the process lifetime, including an empty one. On
sqlite-elasticsearch, startup seeding races the ES sync, the first request sees an empty (but 200) answer, and the pages stayed broken forever — 18 browser tests failed as a cluster in run 30582018605. Empty successes are now served for their request only, exactly like failures already were, so the pages self-heal once the index catches up. The server-side facet of #462 (CDs never syncing at all on that leg) stays open.Tests: next-link discovery + rebase units, a paging round-trip against an in-process axum server that advertises its next page under a foreign base URL, and warming-source tests on both catalogs (first fetch empty → second request re-fetches and sees data).
helios-ui110 tests green.