session: the snapshot's regions follow the scenario, every readout - #740
Merged
Merged
Conversation
Regions applied to a running mesh reached the scenario - the firmware was provisioned from them and relayed scoped traffic normally - but vanished from nodes.list within a tick, so the one place the manual says regions can be read answered 'no regions' on a mesh where every node held one. infer.apply and nodes.regions write both the scenario and the published row, and something on a warmed, playing mesh rebuilt the rows without the regions; I could not isolate which rebuild, and neither could the reporter. Rather than chase a transition that hides, the readout now re-projects the scenario's regions and default scope onto the rows every readout, the way it already re-projects the scores, trails and stats from the engine. The scenario is authoritative - it is what the verbs write and what the firmware runs on - so the row cannot drift from it for longer than a readout, whatever rebuilt it. Closes #737 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6
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
2 participants
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.
Regions applied to a running mesh reached the scenario and the firmware - the mesh relayed scoped traffic normally,
infer.applyansweredapplied: 45- butnodes.listread0 of 60within a tick, permanently (#737). Since v0.0.11's docs correctly point the reader atnodes.listas the only place regions can be read, this reads as the apply step having failed on a mesh where it worked.infer.applyandnodes.regionswrite both the scenario node and the published snapshot row. On a warmed, playing mesh the row was rebuilt without the regions. I could not isolate which rebuild does it - nor could the reporter, who ruled outfirmware.set,console.type,nodes.select,sim.pause/sim.play, timers and fresh sockets, and saw a plainnodes.regions+ tick model repro survive (I reproduced that too: it passes).So rather than chase a transition that hides, this makes the fix at the read side's source of truth: the readout re-projects the scenario's
RegionsandDefaultScopeonto the snapshot rows every readout, exactly as it already re-projects scores, trails and stats from the engine. The scenario is authoritative - it is what the verbs write and what the firmware is provisioned from - so a row cannot drift from it for longer than one readout (100 ms), whatever rebuilt it.nodes.listand the Nodes table's region column now both follow the scenario.Unit-tested directly (a drifted row is pulled back to the scenario; a row with no scenario node is left alone; a region-less node stays region-less).
Closes #737
🤖 Generated with Claude Code
https://claude.ai/code/session_01Q9HbD44EKWWTRYgxbFGxf6