ARCH-CAT-003 — Replace browser-authored DQ SQL with a resource API
| Field | Value |
|---|---|
| Status | Open finding; source-verified with captured live failure |
| Severity | High |
| Affected surface | Catalog table Overview and Quality data loading |
| Implementation issue | bff-api #234 |
| Code-change repository | sparqd/bff-api |
Where the problem appears
Open a table in Catalog and inspect the background requests made before selecting Quality.
Concrete observed case
The browser submits internal DQ configuration SQL through the generic SQL execution path. The captured request mixed an internal execution schema with relations in another schema and relied on an internal database routing identifier. Normal Catalog navigation therefore exposed storage layout and produced deterministic server failures.
Expected condition
Catalog requests DQ configuration using the selected canonical table identity. A dedicated BFF resource endpoint owns internal storage names, authorization, query routing, and a stable response model. Quality loads only when first opened.
Cause and evidence
- Overview currently starts DQ configuration reads before the Quality tab is selected.
- The captured request exposed internal SQL and inconsistent schema identity.
- The product already has dedicated DQ behavior that can own this storage boundary.
Why it matters
Internal schema changes leak into the UI contract, authorization is coupled to user SQL access, and opening an unrelated page can create repeated failed queries.
Existing controls and workarounds
Treat Quality as unavailable when its background SQL fails. Do not grant users direct internal-schema access merely to make this browser query succeed.
Alternatives considered
- Recommended: dedicated resource-oriented DQ endpoint keyed by canonical table identity.
- Server-owned query template behind the generic SQL endpoint — still exposes execution semantics and weakens the resource contract.
- Continue browser-authored SQL — rejected because it couples UI behavior to internal storage.
Component involvement
- BFF owns authorization, internal lookup, and the DQ response contract.
- Oqullus requests DQ only on tab activation and renders operation-specific states.
- Platform services own internal DQ storage readiness.
Reproduction and verification
Follow CAT-S020. Record the visible state, request outcome, effective identity, and recovery behavior relevant to this finding.
Resolution conditions
Close when the browser sends no internal DQ SQL or storage identifiers, DQ is loaded on demand, authorization is resource-scoped, and dependency failures have a visible retry path.
Validation and blockers
BFF is primary; Oqullus and data-quality owners participate. Runtime verification needs a usable DQ deployment.