Skip to content

Ledger-append failure loses executed_as provenance: WorkNodeCompleted carries it but update_event_outcome never reads it #279

Description

@rdfitted

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:

  1. QueueManager finalizes a worker and attempts to append the completion fact to the ledger.
  2. The append fails.
  3. It nonetheless publishes a WorkNodeCompleted event whose payload does carry executed_as.
  4. 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions