fix(vprogram): check store dependencies of V-PROGRAM messages at processing time - #1234
Open
odesenfans wants to merge 1 commit into
Open
fix(vprogram): check store dependencies of V-PROGRAM messages at processing time#1234odesenfans wants to merge 1 commit into
odesenfans wants to merge 1 commit into
Conversation
…essing time V-PROGRAM messages were processed without any existence check on the store files they reference, unlike programs and instances which go through find_missing_volumes. A V-Program referencing nonexistent stores was accepted and then parked silently at the scheduler, whose hard lookup was the only guard. Add check_dependencies to VProgramMessageHandler, checking the file pins for the five store references of the content: the runtime manifest, the workload image and its hash tree, and each verified volume and its hash tree. V-Program refs are direct store item hashes (no use_latest / file tag mechanism), so the pin check is sufficient. Missing refs raise VmVolumeNotFound, giving the same retry-then-reject behavior as programs with missing volumes.
foxpatch-aleph
approved these changes
Aug 4, 2026
foxpatch-aleph
left a comment
There was a problem hiding this comment.
The PR correctly adds a check_dependencies override to VProgramMessageHandler that validates all store references (runtime, workload, hash trees, verified volumes) exist as file pins before processing, mirroring the existing pattern in vm.py. The implementation is straightforward, uses the existing find_file_pins accessor and VmVolumeNotFound exception, and is consistent with the codebase conventions. All tests exercising the processing pipeline are updated to seed the required file pins, and a new test validates the rejection path when refs are missing. No correctness, security, or quality issues found.
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.
Problem
V-PROGRAM messages had no dependency existence check:
VProgramMessageHandlerdid not overridecheck_dependencies, andfind_missing_volumesonly branches onProgramContent/InstanceContent. A V-Program referencing store files unknown to the node was processed successfully and then parked invisibly at the scheduler, whose hard lookup was the only guard.This is the pyaleph phase-2 work item recorded in the #1222 review notes (the forget-protection half already landed there via
get_vms_dependent_volumes).Fix
Add
check_dependenciestoVProgramMessageHandler. It checks the file pins for the five store references of the content:runtime.ref(runtime manifest)workload.refandworkload.hash_treerefandhash_treeV-Program references are direct store item hashes (there is no
use_latest/ file tag mechanism for measured content), so the pin check is sufficient. Missing refs raiseVmVolumeNotFound, giving the same retry-then-reject behavior as programs with missing volumes (VM_VOLUME_NOT_FOUND).Out of scope: the balance-removal/GC path not consulting
get_vms_dependent_volumesfor any executable type is a separate, pre-existing gap.Tests
test_process_vprogram_missing_refs: a V-Program with no seeded refs is rejected withVM_VOLUME_NOT_FOUNDand the error details list all five missing refs (written first, watched fail against main).insert_volume_refsin the program tests) so they still exercise their original paths (processing, cost persistence, credit rejection, forget blocking).tests/message_processing/,tests/api/test_vprogram_api.py,tests/db/test_vprograms_db.py,tests/services/test_cost_service_vprogram.py,tests/test_repair.py,tests/jobs/test_check_removing_messages.py: all passing.