glm-5.1
466b121f77
Decompose the reviewed architecture specs into taskgraph-managed tasks: - 2 setup tasks (project init, test infrastructure) - 4 schema tasks (enums, node attrs, edge attrs, graph schemas) - 1 error hierarchy task - 6 graph tasks (FlowGraph class, 3 construction paths, queries, validation) - 5 analysis tasks (type-compat, build-type-edges, ordering, template-validation, defaults) - 5 component tasks (Operation, Sequential, Parallel, Conditional, Map) - 2 host config tasks (GraphologyHostConfig, ReactiveHostConfig) - 4 reactive tasks (WorkflowRoot, node-status, max-concurrency, retry-semantics) - 3 review tasks (foundation, reactive-and-hosts, complete-library) - 5 meta cluster tasks (schema, graph, component, reactive, analysis layers) - 1 API exports task Validated with taskgraph: zero cycles, 38 tasks, 12 parallel generations. Critical path: 12 tasks through reactive execution layer.
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 | pending |
|
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