Files
vigilcare-clinical/docs/resilience/climate/2026-06-24-ack-before-alert-broken.md
2026-06-24 04:35:15 +08:00

43 lines
1.6 KiB
Markdown

# Experiment: Ack Before Alert in Batch
Date: 2026-06-24
Phase: 24 — Climate Resilience Verification
## 1. Hypothesis
If I upload a sync batch containing an alert acknowledgment before the corresponding
alert event, I expect the batch processor to record **CONFLICT** with reason
`ALERT_NOT_YET_SYNCED`, because clinical sync enforces temporal ordering dependencies.
## 2. Baseline
- Test: `ClinicalSyncBatchTests.Processor_ConflictOnAckBeforeAlert`
- Batch contains: `SyncedAlertAcknowledgment` only (no matching `SyncedAlertEvent`)
- Client alert id: newly generated Guid
## 3. Break
```bash
dotnet test VigilCareClinicalAPI.Tests \
--filter "FullyQualifiedName~ClinicalSyncBatchTests.Processor_ConflictOnAckBeforeAlert"
```
Batch payload (wrong order):
```csharp
new ClinicalSyncBatchRequest(batchRef, gatewayId, siteId, capturedAt,
observations: [],
alertEvents: [],
alertAcknowledgments: [new SyncedAlertAcknowledgment(..., clientAlertId, "RN-Smith", ...)],
alertResolutions: []);
```
## 4. Observe
- Batch uploaded successfully (HTTP 201)
- After `ProcessBatchAsync`: batch status = **CONFLICT**
- Conflicts collection contains single entry with `ConflictReason: ALERT_NOT_YET_SYNCED`
- Test result: **Passed** (309 ms)
- No alert row created from premature ack
## 5. Fix / Outcome
- Bug found? **no** — conflict is the correct server-authoritative response
- Fix applied: no fix needed — reorder and re-upload in a new batch (see plan Step 3 for full reorder test)
## 6. Verify
(Conflict assertions captured in `2026-06-24-ack-before-alert-fixed.json`)