Repository navigation
fix(provider-met): search through the paginated v1.1 endpoint - #31
Merged
Merged
Conversation
The Met retired /public/collection/v1/search on 2026-10-01 (410 Gone),
which failed every Met search and the weekly live smoke. /v1.1/search
takes the same filters plus offset/limit and returns one page of ids,
so request exactly the page instead of windowing a full id list.
Object records stay on /v1/objects/{id}.
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
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.
The Met retired
GET /public/collection/v1/searchon 2026-10-01. It now answers 410 Gone, so every Met search failed. The weeklylive-smokerun on 2026-10-05 caught it asmet search failed: 410.Change
/public/collection/v1.1/search. According to the Met's migration notes, it accepts every v1 filter unchanged and keeps the{ total, objectIDs }shape. It addsoffsetandlimitand returns one page of IDs.offsetcomes from the requestedpage, andlimitis the per-search object count, capped at 30 as before. Previously it downloaded every matching ID and sliced a window out of it. Keeping that slice on top ofoffsetwould have made every page after the first come back empty, and a test now pins this./v1/objects/{id}, which is unchanged. AllproviderOptionsfilters are forwarded as before.@refkit/provider-met.Upstream behaviour checked live
offset=0&limit=3followed byoffset=3&limit=3returns the same IDs asoffset=0&limit=6.total, returnsobjectIDs: nullwith status 200. The existing empty-result path handles it.limitabove 500 is capped, andoffset + limitis truncated at 10,000 without an error. The provider asks for at most 30 per page.Testing
Three new unit tests:
offset/limit, and objects come from v1.offset=4/limit=2and maps every ID the page returns.The first two failed on
mainand pass now.REFKIT_LIVE=1Met live smoke passes against the real API.Full gate:
pnpm typecheck,pnpm lint,pnpm build,pnpm test:run(519 passed, 23 skipped),pnpm smoke:artifact.Note: the Met often returns few usable results for a query. Many hits are copyrighted works whose images the Met does not release, and the provider drops those as before. For example, on the first two 4-ID pages for "lighthouse", only one object is public-domain with an image. This is unchanged by this PR.