Repository navigation
fix(runtime): read an action's results under the run it moved in - #1879
Merged
Merged
Conversation
Under -advance the behaviors started move in the clock's run, where the due-order choice point and its marks are recorded, while each executor's own run state stays idle. ResultsWithError entered that idle run to derive the results, so the surface reading the marks afterwards found none and a result standing on the choice point printed bare, without the (order-dependent; 1 choice point — explore shows the set) marker the default run prints. executorRun now records the run its latest call moved the executor in (under: its own state, or the run installed over it when the call was nested, as the clock's advance nests it), beginExecutorRun sets it, and ResultsWithError reads under that run; snapshots and held images carry it with the run state. A CLI test asserts the marker on an -advance run of an action and a state machine due at one instant. Co-Authored-By: jason.han <hanhuijun@gmail.com>
Contributor
Author
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
Merged
4 of 6 tasks
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.
What and why
Bug.
sysml examples/analysis-demo/lander.sysml -instantiate Landers::scout -action Timing::groundWatch -advance 5printssawBraking = [false]bare, although the run's summary says1 choice pointand the same command on v0.11.0 (and the default run without-advanceon develop) printssawBraking = [false] (order-dependent; 1 choice point — explore shows the set). Found by the 0.12.0 release docs audit.Bisected cause.
git bisect v0.11.0..developwith that reproducer names c8e6c9d (#1619,fix(runtime): mark order dependence on chained places and same-step sibling reads). That commit madeActionExecutor.ResultsWithErrorenter the executor's own run state (e.driven.state) before deriving the results, so a derivation would not install a fresh run and drop the marks of the run just ended. Under-advance, though, the behaviors started do not move in their own run states:Context.AdvanceUntilruns them nested under the clock's run (ctx.clockRun), which is where the due-order choice point (ChoiceDueOrder) and its marks are recorded, while each executor's own state stays idle (no notes, no marks). Entering that idle state installed it over the clock's run, sonamedValue→Context.OrderDependentread it afterwards and found no choice point: the marker vanished only on the-advancepath (default runs and-schedule exploremove in the executor's own run, where state and clock coincide).Fix.
executorRunnow records the run its latest call moved the executor in (under: its own state, or the run installed over it when the call was nested, as the clock's advance nests it);beginExecutorRunsets it andResultsWithErrorreads under that run instead of the idle one. Snapshots (actionCapture/stateCapture) and held images (imagedAction/imagedState) carry it beside the run state so a restore keeps the pair consistent. Nothing prints the marker unconditionally and no output is patched:OrderDependentsimply reads the run that holds the marks.Specification basis
No new clause; this restores the surface described by the existing row of
docs/project/spec-compliance.md("A default run reports its values only up to the partial order the library fixes…", KerML 1.1 §9.2.4 Occurrences, §9.2.6 Performances): a value a conflicting alternative wrote prints with the marker on every surface. The row's implementation note forResultsWithErrorand its test list are updated; the row's status does not move.docs/internals/design/scheduling.mddescribes the same read and is updated.How it was verified
New
cmd/sysml/run_test.go:TestAdvanceMarksOrderDependentResults(red on develop, green here) asserts the marker on-advance 5over the existingdueTogetherModel(an action and a state transition due at one instant), beside the explore test of the same fixture.Reproducer on the lander example:
v0.11.0 (
git worktreeat the tag):develop (1dc7d36):
this branch:
Gates (local):
go build ./... → ok
go vet ./... → ok
make lint → ✓ Lint passed (staticcheck + gosec)
python3 scripts/changelog.py check → ok
go test ./internal/exec/runtime/... ./internal/frontend/repl/... ./cmd/sysml/... → ok
go test ./... -timeout 40m → ok (every package; exit 0)