orchestrator: Let Platform::execute return a follow-up event - #419
Open
chrysh wants to merge 3 commits into
Open
orchestrator: Let Platform::execute return a follow-up event#419chrysh wants to merge 3 commits into
chrysh wants to merge 3 commits into
Conversation
An executor that learns something synchronously — a verification verdict — had no way to feed it back; every shell needed its own queue, drained between dispatches. execute now returns Result<Option<Event>, EffectError>: the driver queues the returned event and settles it in the same run, so one dispatch runs to quiescence. The pending queue pops as it settles, bounding it by in-flight events instead of a run's length; overflow injects EffectFailed and latches Locked — the same fail-closed rule as a failed effect. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
chrysh
force-pushed
the
platform-event-return
branch
from
August 14, 2026 17:13
246c9b7 to
61610d8
Compare
A failed effect with a full pending queue silently dropped the EffectFailed push: failed stayed set, nothing latched, and the run settled as if the actuation had succeeded. Fold both failure paths into one latch() helper: evict the newest queued event if the queue is full, and push the latch to the *front*, so it settles next and queued feedback drains into Locked instead of actuating hardware after a failure. Document that returned events must quiesce. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
PR OpenPRoT#357 renamed the effect-executing layer to platform driver; the SM doc comments still said shell. Wording only. Assisted-by: Claude:claude-fable-5 Signed-off-by: Christina Quast <christina.quast@9elements.com>
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.
TL;DR: @rusty1968 Should the orchestrator SM have a que to get the events back, or should each shell implement their own queue?
An executor that learns something synchronously — a verification verdict — has no way to feed it back through
Platform::execute, so every shell needs its own event queue drained between dispatches.executenow returnsResult<Option<Event>, EffectError>: the driver queues a returned event and settles it in the same run, so one dispatch runs to quiescence. The internal pending queue pops as it settles, so it bounds in-flight events instead of a run's total length; a queue overflow injectsEffectFailedand latchesLocked— the same fail-closed rule as a failed effect. At most one event per effect; results that arrive later (boot progress, timer expiry) stay outside events.Breaking change to the
Platformseam. The shell (#418) currently works around the gap with a shell-side queue and drops it once this lands.