Skip to content

fix(provenance): derive final-output provenance instead of declaring it unvouchable - #7173

Merged
icecrasher321 merged 1 commit into
stagingfrom
provenance-finaloutput-producer
Aug 27, 2026
Merged

fix(provenance): derive final-output provenance instead of declaring it unvouchable#7173
icecrasher321 merged 1 commit into
stagingfrom
provenance-finaloutput-producer

Conversation

@icecrasher321

Copy link
Copy Markdown
Collaborator

Summary

  • Fixes the live producer behind the TraceStore — displayProjection stream that is now ~95% of provenance log output (105 of 110 lines post-deploy). Every one of those lines is parts: ["finalOutput"], and the stock is real and growing — 30 distinct executions in under 4 hours — so this was never just a fixed backlog of bug-era rows.
  • Root cause: ExecutionEngine.setFinalOutput stamped { complete: false } whenever the final block's state carried no provenance. But an absent block-state envelope is not a verdict — several state writers legitimately omit one, and a subflow sentinel aggregating iteration results is the common case (a loop that ran no iterations has nothing to merge, so setBlockOutput is called without provenance). The affected production workflows end in a loop block, which is exactly this shape.
  • The cost was user-facing, not just log noise. An incomplete final-output envelope makes the display projection withhold finalOutput, so the workflow's author could not see their own run's output in the execution log — on every view, permanently. Each view then re-derived the same verdict, which is the read-path re-fire dominating the stream.
  • The fix: derive from the run registry against the value being described — precisely what the end-of-run path (ensureFinalOutputProvenance) already did, and what every other consumer of a provenance-less block state does (the trace-store block-output reader falls back to the run registry). The two paths now share one deriveFinalOutputProvenance rather than disagreeing: take the block state's exact envelope as a shortcut when present, derive otherwise.
  • Still fails closed: exportCommittedProvenanceForValue returns an incomplete envelope when the registry itself latched, which is the genuinely unvouchable case. That guard has its own regression test.

Type of Change

  • Bug fix

Testing

Two new engine tests: one pins the derivation (a final block whose state carries no provenance yields a complete envelope naming the secret actually present in the output), one pins fail-closed (a latched registry still exports incomplete). Verified the derivation test fails without the fix and passes with it. 5,071 tests green across executor/, lib/logs/, and lib/workflows/; bun run type-check clean; all 36 audits pass.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

…it unvouchable

A run whose last block stored its output without provenance had its
final-output envelope stamped incomplete. That is not what an absent
block-state envelope means: several state writers legitimately omit one,
and a subflow sentinel aggregating iteration results is the common case
— a loop that ran no iterations has nothing to merge, so its aggregate
carries none. The workflows hitting this in production end in a loop.

The cost was not noise. An incomplete final-output envelope withholds
finalOutput from the execution log, so the author of the workflow could
not see their own run's output, on every view, forever — and each view
re-derived the same verdict, which is the read-path re-fire now
dominating the provenance stream.

Derive from the run registry against the value being described, which is
what the end-of-run path already did and what every other consumer of a
provenance-less block state does. The two now share one derivation
rather than disagreeing: a shortcut when the block state has an exact
envelope, the registry otherwise. It fails closed on its own terms —
a latched registry still exports incomplete — and the guard for that is
pinned by its own test.
@vercel

vercel Bot commented Aug 27, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Aug 27, 2026 8:38pm

Request Review

@greptile-apps

greptile-apps Bot commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR fixes final-output provenance for terminal block states that omit their own provenance envelope by deriving it from the run registry. It also consolidates end-of-run derivation behind one helper and adds regression coverage for successful derivation and permanently incomplete registries.

  • Replaces the unconditional incomplete envelope with value-specific committed provenance derivation.
  • Preserves exact block-state provenance when available.
  • Retains fail-closed behavior for permanently incomplete registries.
  • Adds tests for provenance-less final blocks and latched registries.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness or security issues identified.

The changed path derives provenance only when the final block lacks an exact envelope, uses the established committed-value registry export, and continues to return incomplete provenance when the registry cannot vouch for the run.

Important Files Changed

Filename Overview
apps/sim/executor/execution/engine.ts Centralizes final-output provenance derivation and uses the committed run registry when the terminal block state has no provenance.
apps/sim/executor/execution/engine.test.ts Adds focused regression tests for successful registry derivation and fail-closed handling of an incomplete registry.

Reviews (1): Last reviewed commit: "fix(provenance): derive final-output pro..." | Re-trigger Greptile

@cubic-dev-ai cubic-dev-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No issues found across 2 files

Confidence score: 5/5

  • Automated review surfaced no issues in the provided summaries.
  • No files require special attention.

Re-trigger cubic

@icecrasher321
icecrasher321 merged commit b6a235c into staging Aug 27, 2026
30 checks passed
@waleedlatif1
waleedlatif1 deleted the provenance-finaloutput-producer branch August 27, 2026 23:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant