Skip to content

A parallel scope keeps its own fork activation - #145

Merged
noha merged 1 commit into
mainfrom
parallel-scope-keeps-its-fork
Sep 21, 2026
Merged

noha merged 1 commit into
mainfrom
parallel-scope-keeps-its-fork

Conversation

@noha

@noha noha commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

FBBaseExecutor>>activationOf: answers the most recent activation of a node. A node has one activation per pass through the same fork, so the most recent activation of a fork is only the asking scope's while that scope is the one running - once it is over, the newest belongs to a later pass.

A finished scope therefore read a running one's fork. #outputFor: asks whether the loop is over, was told "no" by another loop, and answered the slot of its own last iteration instead of its first value: the same activation said one thing while the second pass ran and another once everything was over.

The scope resolves its fork once, on the first use - which is the first step of its own scope, when the newest activation of that fork is still its own, since a second pass cannot start before the scope is popped - and keeps it. Every other node is looked up as before; for those the most recent one is right, because only a live scope looks a node up and its own activations are the newest there are.

Found while tracing a customer report of 2026-09-18 (a loop that ran twice wrote its first pass's last element 300 times); the reading path that report went through is ApptiveScript's step(id), fixed separately in apptive-base.

FBBaseExecutor>>activationOf: answers the most recent activation of a
node. A node has one activation per pass through the same fork, so the
most recent activation of a fork is only the asking scope's while that
scope is the one running - once it is over, the newest belongs to a
later pass.

A finished scope therefore read a running one's fork. #outputFor: asks
whether the loop is over, was told "no" by another loop, and answered
the slot of its own last iteration instead of its first value: the same
activation said one thing while the second pass ran and another once
everything was over.

The scope resolves its fork once, on the first use - which is the first
step of its own scope, when the newest activation of that fork is still
its own, since a second pass cannot start before the scope is popped -
and keeps it. Every other node is looked up as before; for those the
most recent one is right, because only a live scope looks a node up and
its own activations are the newest there are.

Found while tracing a customer report of 2026-09-18 (a loop that ran
twice wrote its first pass's last element 300 times); the reading path
that report went through is ApptiveScript's step(id), fixed separately
in apptive-base.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@noha
noha merged commit 8a65302 into main Sep 21, 2026
4 checks passed
@noha
noha deleted the parallel-scope-keeps-its-fork branch September 21, 2026 17:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant