Rail: graph-stamped unique_source_id powers the Stakwork lineage link - #5072
Open
tomsmith8 wants to merge 3 commits into
Open
Rail: graph-stamped unique_source_id powers the Stakwork lineage link#5072tomsmith8 wants to merge 3 commits into
tomsmith8 wants to merge 3 commits into
Conversation
jarvis-backend stamps unique_source_id (the Stakwork project id) on nodes at dispatch — the proposed-fixes route already reads it with project_id as legacy fallback. That is the graph->run key concept attempts were missing: they carry no evalTriggerRef anywhere, so the rail could only show em-dashes for them. - The walker now carries edge properties through (some writers stamp unique_source_id on edges rather than nodes) - Charted rows resolve a graph project id (output node -> owning trigger node -> touching edges, unique_source_id before project_id) and use it as a second join key against all three run lists, giving concept attempts real status, run type, and report state when a run row exists - When no run row exists at all, the graph-stamped project id still powers the super-admin Stakwork link, so every attempt is openable
Field data shows the stamp can be the ROOT PARENT's Stakwork project (the orchestrating dispatch), not the re-runner that produced the specific attempt. Joining status/report on it would let a rerun row wear the parent run's outcome — including its report link, which would be factually wrong on that row. The graph-stamped project id now powers ONLY the super-admin Stakwork link (lineage: the project that orchestrated the attempt). Status, run type, and report state join exclusively on result.evalTriggerRef, the one key that is per-attempt by construction.
tomsmith8
changed the title
|
Test environment is now live. View it at: https://hive-preview-3.sphinx.chat Database expires at: Aug 19, 2026, 11:34 PM UTC |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #5070 (merged while the first commit was in flight — cherry-picked, then revised as the
unique_source_idsemantics were pinned down).The topology
Per recursion iteration:
So the graph stamp is true per-attempt identity — of the child re-runner — while hive's run rows only ever carry the parent's project id. The two id spaces never meet, which dictates the design:
projectIdmatch against hive rows would be coincidence, not identity. Status / run type / report state join exclusively onresult.evalTriggerRefMechanics
unique_source_idbefore legacyproject_id(same precedence the proposed-fixes route established)Testing
Hook + walker suites: the stamp never wears a coincidentally-matching run's status/report (pinned), the link survives with no run row at all, edge-property resolution, plus existing
evalTriggerRefjoin coverage.