PERF-ONT-001 — Page the complete object list
| Field | Value |
|---|---|
| Status | Open finding; source-verified |
| Severity | High beyond 50 objects |
| Components | sparqd/oqullus, sparqd/ontology, sparqd/bff-api |
| Associated issues | sparqd/oqullus#549 |
Concrete observed case
The branch endpoint defaults to 50 items at offset zero and returns total.
Oqullus calls it without pagination or search parameters, keeps only items,
loads every returned object again to calculate three counts, and creates local
pages of eight. The default order is object name. The Latest First option
does not sort and timestamps are absent from the summary.
With 51 objects, the alphabetically 51st object is never fetched. It cannot be found by client search or page navigation, although direct UUID retrieval and Cube's separate complete-model load can still see it.
Expected condition
List, search, and sort operate over the complete authorized project/branch result set using server pagination. Summary rows include display counts and a real sortable update timestamp, and loading one page requires a bounded number of requests and database rows.
Why it matters
The management UI can deny the existence of a model that Cube still compiles and queries. This is product correctness, not only slow performance. The N+1 detail fan-out also increases latency and backend load before the 50-item limit.
Existing controls and workarounds
A user who already knows the object UUID may open it directly. Semantic Query and Cube use different loading paths. Neither is a practical object-management or discovery workaround.
Alternatives considered
- Recommended: server-side search/sort/page plus counts in the summary response and a bounded effective-model projection.
- Request the endpoint maximum of 200 once — delays the same correctness limit and retains N+1 requests.
- Infinite scroll over server pages — acceptable presentation if total, loading, retry, and stable ordering remain explicit.
Component involvement
- Oqullus sends search, sort, limit, and offset/cursor; consumes
total; and removes per-row detail fan-out. - Ontology backend produces stable, bounded pages without materializing the complete effective model for every page.
- BFF preserves parameters and response metadata.
Reproduction and verification
Follow ONT-S006.
Resolution conditions
Close when the 51st and later objects are discoverable by list and search, Latest First uses authoritative time, pagination remains stable during changes, one page uses bounded requests, and representative large-project benchmarks are recorded.
Validation and blockers
The first-page-only path is source-confirmed. A 51-object deployed fixture and agreed scale target remain open.