REL-WSF-002 — Separate request failure from empty state
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Severity | High |
| Components | sparqd/oqullus, sparqd/bff-api |
| Associated issues | Not opened |
Concrete observed case
General workspace load logs an error without surfacing it. Folder-target and
permission helpers return [] on failure. Trash logs and retains its prior or
initial state. The same UI can therefore mean genuinely empty, unauthorized,
temporarily unavailable, or stale.
Expected condition
Each view has explicit loading, loaded-empty, loaded-data, stale-data, denied, and failed states. Known data remains visible as stale when safe, and retry is available.
Why it matters
Users may assume files or grants disappeared, select the wrong move target, or make access changes without seeing current permissions.
Existing controls and workarounds
Some operations emit a toast and browser developer tools retain the failed request. Refresh the view before concluding data is absent.
Alternatives considered
- Recommended: a shared typed query state and error boundary per operation.
- Toast-only errors — insufficient because the underlying view remains ambiguous.
- Replace with empty arrays — current behavior and rejected.
Component involvement
- Oqullus owns typed request state, stale-data presentation, retry, and operation-specific feedback.
- BFF API preserves actionable status codes and correlation identifiers.
Reproduction and verification
Follow WSF-S007.
Resolution conditions
Close when fault-injection UI tests distinguish every state and successful retry reconciles without duplicate actions.
Validation and blockers
Catch behavior is source-confirmed. Deployed network and backend fault exercises remain pending.