Found by the #448 R4 parameter sweep. GET /SearchParameter?_summary=count&_total=accurate reports 1377 parameters, but GET /SearchParameter?_count=10000 returns 1000 entries — the server caps _count at 1000 and the UI's conformance self-fetch (HttpConformanceSource, which asks for 10000 and assumes one page is enough) silently loses the remaining 377. The viewer's "All types" chip reads 1000, which matches.
Options: follow next links in the self-fetch (robust against any cap), raise the cap for conformance types, or page explicitly with _count=1000&_offset. Following next seems the honest fix — the "one big page" assumption in crates/ui/src/conformance.rs was already flagged as capped for the ES max_result_window, and it should not silently under-report whatever the server's policy is.
Same truncation presumably affects the compartments fetch on servers with >1000 CompartmentDefinitions (unlikely) and any future conformance viewer.
Part of the #448 sanity pass.
Found by the #448 R4 parameter sweep.
GET /SearchParameter?_summary=count&_total=accuratereports 1377 parameters, butGET /SearchParameter?_count=10000returns 1000 entries — the server caps_countat 1000 and the UI's conformance self-fetch (HttpConformanceSource, which asks for 10000 and assumes one page is enough) silently loses the remaining 377. The viewer's "All types" chip reads 1000, which matches.Options: follow
nextlinks in the self-fetch (robust against any cap), raise the cap for conformance types, or page explicitly with_count=1000&_offset. Followingnextseems the honest fix — the "one big page" assumption incrates/ui/src/conformance.rswas already flagged as capped for the ES max_result_window, and it should not silently under-report whatever the server's policy is.Same truncation presumably affects the compartments fetch on servers with >1000 CompartmentDefinitions (unlikely) and any future conformance viewer.
Part of the #448 sanity pass.