Trace GPS resolver during map queries

This commit is contained in:
2026-06-20 21:56:36 -05:00
parent 407c44b1ad
commit 1d77b8483f
3 changed files with 171 additions and 43 deletions
+8 -4
View File
@@ -81,10 +81,14 @@ Active build note:
This is meant to identify whether class/mask filtering, rather than the edge
multiplier table, is dominating route choice.
- The resolver probe logs selected packed-handle resolutions from the
search/materialization corridor. It decodes point index, segment index, and
generation bits, then dumps the resolved 0x68-byte segment record and
0x14-byte point record. The purpose is to see whether the edge-cost stage can
reach final lane hashes/resource-side road classes before a path is chosen.
search/materialization corridor. The selected post-call return sites are
`0x44cb9e` (0x38 intermediate-record builder) and `0x44dd97`
(geometry/materialization path). For full-map GPS queries from caller
`0x8d20d4` with `query_fcc=5`, it opens a five-second resolver trace window,
decodes point index/segment index/generation bits, then dumps the resolved
segment/point records plus small raw slices behind segment pointer fields.
The purpose is to see whether route materialization can reach final lane
hashes/resource-side road classes before the final 0x28 records are emitted.
Current route-probe focus: