jan/rrt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Narrow region restore continuation candidates

Browse source
This commit is contained in:
Jan Petykiewicz 2026-04-18 20:38:09 -07:00
commit 69022731ee
2 changed files with 15 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

3
crates/rrt-runtime/src/smp.rs
View file

@ -5038,13 +5038,14 @@ fn build_region_service_trace_report(
],
evidence: vec![
"the checked-in region trace already grounds 0x00444887 as the first caller-side checkpoint above 0x00421510: it refreshes the region collection and then immediately advances into the territory and support collection refresh owners".to_string(),
"the neighboring atlas-backed restore symmetry already rules the territory side down somewhat too: 0x00487c20 only restores the live territory collection metadata/id family and its current per-entry slots 0x00487670/0x00487680 are still no-op load/save callbacks, so the territory leg now looks less likely than support or a later region-local rebuild to hide [region+0x2a4] or [region+0x310/+0x338/+0x360]".to_string(),
"the same grounded evidence already narrows the later per-region follow-on too: 0x00444b90 dispatches 0x00420560 over each live region after the broader restore continuation has already advanced".to_string(),
"direct disassembly already rules that per-region follow-on down as a latch owner: 0x00420560 only zeroes and recomputes [region+0x312] from the embedded profile collection [region+0x37f]/[region+0x383] and lazily seeds the year-driven [region+0x317/+0x31b] band through 0x00420350, not [region+0x276/+0x302/+0x316]".to_string(),
"that leaves the broader 0x00444887 continuation as the next structured restore seam above the ruled-down 0x00421510 -> 0x0041f5c0 -> 0x00455fc0 path when chasing acquisition-side lanes [region+0x2a4] and [region+0x310/+0x338/+0x360]".to_string(),
],
blockers: vec![
"the concrete later-global restore owner that rehydrates [region+0x2a4] and [region+0x310/+0x338/+0x360] is still not grounded below the 0x00444887 continuation".to_string(),
"territory and support collection refresh owners are adjacent in the same continuation and may still carry shared prerequisites before the region-side rebuild resumes".to_string(),
"support collection refresh 0x0040b5d0 and the later region-local rebuild remain the strongest adjacent prerequisites now that territory refresh 0x00487c20 is partly ruled down as metadata/id-only".to_string(),
],
},
SmpServiceConsumerHypothesis {

13
docs/rehost-queue.md
View file

@ -608,6 +608,19 @@ Working rule:
`[this+0x20]`, `[this+0x8d]`, `[this+0x5c..+0x61]`, `[this+0x1ee]`, `[this+0x1fa]`, and
`[this+0x3e]`, and then it opens `0x55f3` only for span accounting before returning. So the
missing region latches are not hiding in the remainder of `0x00455fc0` either.
- The next restore-handoff strip is explicit now too: the region trace now carries a dedicated
later-global-restore hypothesis for `0x00444887`, because that continuation is the first caller
checkpoint above the ruled-down `0x00421510 -> 0x0041f5c0 -> 0x00455fc0` path. It immediately
advances into `0x00487c20` territory refresh and `0x0040b5d0` support refresh, then later
re-enters the per-region follow-on loop at `0x00444b90 -> 0x00420560`. Current disassembly keeps
`0x00420560` on `[region+0x312]` / `[region+0x317/+0x31b]` only, so the next region pass should
treat the broader `0x00444887` continuation as the live handoff seam when chasing
`[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`, not as just another generic restore note.
- That same continuation is slightly less symmetric now too: the atlas-backed territory side at
`0x00487c20` currently restores only collection metadata/live ids and still uses no-op per-entry
load/save callbacks `0x00487670/0x00487680`, so the next pass should bias more heavily toward
support refresh `0x0040b5d0` or the later region-local rebuild than toward territory payload as
the hidden source of `[region+0x2a4]` and `[region+0x310/+0x338/+0x360]`.
- The later restore-side region owners are narrowed further now too: the `0x00421ce0 ->
0x0041fb00 -> 0x00421730` sweep is class-`0` raster/id rebuild, `0x004881b0` is a companion
region-set cell-count rebuild over `[region+0x3d/+0x41]`, `0x00487de0` is a border-segment