1.5 KiB
1.5 KiB
id, name, status, depends_on, scope, risk, impact, level
| id | name | status | depends_on | scope | risk | impact | level | |
|---|---|---|---|---|---|---|---|---|
| reactive/retry-semantics | Implement retry semantics — event log append with new requestId, status projection respects retries | completed |
|
narrow | medium | component | implementation |
Description
Implement the retry semantics where retries are natural append events. A retry creates a new call.requested with a new requestId, and the status projection derives the current state by scanning for the most recent event per node. No retried status or state mutation needed.
Acceptance Criteria
nodeKeyToRequestId.set(nodeKey, newRequestId)overwrites the previous requestId — the projection tracks the latest attemptgetResult()derives from the most recent terminal event (responded/error/aborted) for the current requestId- Retry sequence:
call.error(requestId=1)→call.requested(requestId=2)→call.responded(requestId=2)→ status is "completed" (from latest event) - Previous attempt events preserved in
eventLog— full history maintained - Conditional.test and Map.over see the latest result including retry outcomes
- Unit tests: retry sequence produces correct final status, getResult reflects latest attempt, event log preserves full history
References
- docs/architecture/reactive-execution.md — retry semantics, event-to-status mapping
- docs/architecture/schema.md — CallEventMapValue
Notes
To be filled by implementation agent
Summary
To be filled on completion