Follow-up from #268 / PR #275. Raised by CodeRabbit on src-tauri/src/orchestrator/work_graph/runtime.rs:1561, adjudicated as valid but out of scope for that PR.
The problem
#274 records executed_as on completion facts, and the archive projection copies it from the fact onto the RuntimeOutcome.
But there is a path where the fact does not exist:
QueueManager finalizes a worker and attempts to append the completion fact to the ledger.
- The append fails.
- It nonetheless publishes a
WorkNodeCompleted event whose payload does carry executed_as.
update_event_outcome does not read that event payload.
Result: runtime progress and archived outcomes silently lose the execution provenance for that node, even though the information was captured and published. The retro's TaskTierRunMetric will then classify that node's evidence as partial via ExecutedAsUnavailable — which is honest, but the data was actually available and got dropped.
Why it was not fixed in #275
It is a genuine correctness gap, but a failure-path one that needs a design decision rather than a patch: should update_event_outcome become event-sourced for execution provenance generally, or should this specific field be reconciled from the event payload as a special case? The first is a broader change to how runtime outcomes derive from events; the second adds a second source of truth for one field.
Patching it hastily risks introducing a path where event-derived and fact-derived provenance disagree, which is worse than the current honest-but-lossy behaviour.
Reproduction sketch
Force the ledger append to fail during queue finalization (inject an IO error or a read-only ledger path), then inspect the resulting RuntimeOutcome and the archived progress projection — executed_as is absent despite the published event carrying it.
Suggested acceptance
- A decision recorded on which of the two designs applies.
- Provenance preserved across a failed ledger append.
- A test that fails the append and asserts the outcome still carries
executed_as.
Follow-up from #268 / PR #275. Raised by CodeRabbit on
src-tauri/src/orchestrator/work_graph/runtime.rs:1561, adjudicated as valid but out of scope for that PR.The problem
#274recordsexecuted_ason completion facts, and the archive projection copies it from the fact onto theRuntimeOutcome.But there is a path where the fact does not exist:
QueueManagerfinalizes a worker and attempts to append the completion fact to the ledger.WorkNodeCompletedevent whose payload does carryexecuted_as.update_event_outcomedoes not read that event payload.Result: runtime progress and archived outcomes silently lose the execution provenance for that node, even though the information was captured and published. The retro's
TaskTierRunMetricwill then classify that node's evidence aspartialviaExecutedAsUnavailable— which is honest, but the data was actually available and got dropped.Why it was not fixed in #275
It is a genuine correctness gap, but a failure-path one that needs a design decision rather than a patch: should
update_event_outcomebecome event-sourced for execution provenance generally, or should this specific field be reconciled from the event payload as a special case? The first is a broader change to how runtime outcomes derive from events; the second adds a second source of truth for one field.Patching it hastily risks introducing a path where event-derived and fact-derived provenance disagree, which is worse than the current honest-but-lossy behaviour.
Reproduction sketch
Force the ledger append to fail during queue finalization (inject an IO error or a read-only ledger path), then inspect the resulting
RuntimeOutcomeand the archived progress projection —executed_asis absent despite the published event carrying it.Suggested acceptance
executed_as.