ci: fix panic reading rust-step side effects in source release job - #4239
Merged
Ben Hillis (benhillis) merged 1 commit intoAug 13, 2026
Conversation
The first dispatch of the OpenVMM source release workflow aborted in
`pin source release tag` with::
db is missing var auto_se:flowey_lib_hvlite::_jobs::publish_openvmm_gh_release:13
The side effect that `emit_rust_step` hands back is only ever claimed,
never written to the runtime var db, so `rt.read()` on one panics. It
is the claim that creates the dependency edge, so ordering still holds
without the read.
Drop the read in the pin step, and drop the equivalent read of
`prerequisites` in the shared publisher, which would have hit the same
panic one step later once a non-empty prerequisite list was passed.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 2f283c1b-ae06-4449-9ac9-897cd279f65e
Contributor
There was a problem hiding this comment.
Pull request overview
Fixes a runtime panic in Flowey-based CI/release pipelines by ensuring rust-step SideEffect vars are used strictly for dependency ordering (claimed) and never read at runtime.
Changes:
- Stop reading a rust-step
SideEffectin the OpenVMM source release job; claim it only to preserve DAG ordering. - Remove runtime
rt.read()ofprerequisitesin GitHub release publishing, relying onGhReleaseParams::claimfor ordering. - Add clarifying comments documenting the “claim-only, never read” contract for rust-step side effects.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| flowey/flowey_lib_hvlite/src/_jobs/publish_openvmm_gh_release.rs | Avoids rt.read() on a rust-step side effect that is never written to the var DB, preventing the observed panic. |
| flowey/flowey_lib_common/src/publish_gh_release.rs | Documents and enforces claim-only prerequisites ordering by removing runtime reads that could panic when prerequisites are rust-step side effects. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Ben Hillis (benhillis)
enabled auto-merge (squash)
August 13, 2026 19:50
Steven Malis (smalis-msft)
approved these changes
Aug 13, 2026
Ben Hillis (benhillis)
disabled auto-merge
August 13, 2026 20:34
Ben Hillis (benhillis)
merged commit Aug 13, 2026
e01a057
into
microsoft:main
68 of 70 checks passed
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
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.
The first real dispatch of the OpenVMM source release workflow (run 31733701937) aborted in the
pin source release tagstep:thread 'main' panicked at flowey/flowey_core/src/node.rs:1800:32: db is missing var auto_se:flowey_lib_hvlite::_jobs::publish_openvmm_gh_release:13Root cause
The
SideEffectthatctx.emit_rust_stephands back is created vianew_prefixed_var("auto_se")and claimed for write on behalf of the step, but nothing ever writes it to the runtime var db. It is the claim in a downstream step that creates the dependency edge in the DAG; the value is never meant to be read. Callingrt.read()on one therefore panics inRuntimeVarDb::get_var.The established idiom elsewhere in the tree (e.g.
download_openvmm_vmm_tests_artifacts) is to claim the side effect and never read it.Fix
publish_openvmm_gh_release: claimno_existing_releasewithout reading it.publish_gh_release: drop the equivalentrt.read(prerequisite)loop.prerequisitesis already claimed inGhReleaseParams::claim, so ordering is unaffected. This path had never executed — the only prior caller passesVec::new()— and would have hit the identical panic one step later, sincetag_is_pinnedis also a rust-step side effect.Comments added at both sites so this doesn't get reintroduced.
Validation
cargo clippy -p flowey_lib_hvlite -p flowey_lib_common --all-targetsandcargo xtask fmtboth clean; no generated workflow YAML changes.