REL-ONT-001 — Surface dynamic model dependency failures
| Field | Value |
|---|---|
| Status | Open finding; source-verified |
| Severity | High |
| Components | sparqd/platform-stacks, Cube, sparqd/ontology, sparqd/oqullus |
| Associated issues | sparqd/platform-stacks#680 |
Concrete observed case
The deployed Cube configuration catches failure while loading the Ontology repository and returns an empty file list. It separately catches schema-version failure and returns a fixed default. Both paths log on Cube but erase the dependency failure from the model input returned to the request.
Expected condition
A model dependency failure is returned and observed as such. If last-known-good serving is intentionally supported, the response and UI disclose staleness, model revision, failure time, and recovery state; the cache is bounded and cannot silently become an empty model.
Why it matters
Users can receive missing-cube or empty-model behavior and troubleshoot their definition even though ontology-backend is unavailable. A default schema version can also delay or obscure recompilation recovery.
Existing controls and workarounds
Cube logs the caught exception. Operators can correlate logs manually. Users have no attributable error or safe way to distinguish invalid model content from an Ontology dependency outage.
Alternatives considered
- Recommended: fail the compiler/request with a typed upstream dependency error and expose it through the semantic-query path.
- Serve a durable last-known-good model with explicit stale metadata and alerts; useful for availability but substantially more state and policy.
- Return
[]and a default version — current behavior, rejected because it converts failure into plausible model state.
Component involvement
- Platform stacks owns the Cube failure policy implemented in
cube.js. - Cube must preserve an attributable compilation or dependency error.
- Ontology backend exposes health and revision evidence.
- Oqullus presents dependency failure separately from invalid user models.
Reproduction and verification
Follow ONT-S007.
Resolution conditions
Close when repository and schema-version failures cannot appear as a valid empty model, user and operator errors identify Ontology, recovery recompiles the intended revision, and alerting covers the failure and any stale serving mode.
Validation and blockers
The fallback is source-confirmed. Live fault injection and the product decision between fail-closed and last-known-good serving remain open.