REL-WSF-003 — Report partial batch-upload outcomes
| Field | Value |
|---|---|
| Status | Open; source-verified |
| Severity | Medium |
| Components | sparqd/oqullus, sparqd/bff-api, sparqd/workspace-file-management-backend |
| Associated issues | Not opened |
Concrete observed case
Oqullus starts one request per selected file under Promise.all. Backend
requests commit independently. If one fails after another succeeds, the batch
shows one failure message and skips the folder refresh, hiding the successful
partial result until a later reload.
Expected condition
The UI reports status per file, refreshes committed results, and retries only failed items with idempotency protection.
Why it matters
Users can retry already committed files, create conflicts, or assume successful uploads were lost because the folder did not refresh.
Existing controls and workarounds
Upload one file at a time and refresh after any error before retrying.
Alternatives considered
- Recommended: bounded worker queue with
allSettled, per-file state, and idempotency keys. - Transactional batch endpoint — difficult across large object uploads and still requires compensation.
- Sequential uploads — simpler partial reporting but unnecessarily slow and still needs idempotency.
Component involvement
- Oqullus bounds the queue and reports each result.
- BFF API forwards idempotency and limit metadata.
- The backend makes create/finalize retries safe and exposes committed outcome.
Reproduction and verification
Follow WSF-S002.
Resolution conditions
Close when mixed success, timeout, cancel, duplicate retry, and refresh tests show the exact committed set without duplicates.
Validation and blockers
Independent commit and aggregate client handling are source-confirmed. A mixed deployed batch test remains pending.