- the PBR SFIs were learned only by the tracker; the message decode's
per-channel SFI map still did not know them, so the SEARCH RECORD addressed
by SFI 2 after the PBR read showed "SFI 2, unknown file" (the reported
case: session 193, 5.434 s — the PBR read at 4.451 declared ADN 4F3A/SFI 2)
- database._advance_state now parses an EF_PBR record it sees (a READ
RECORD's data or an UPDATE RECORD's body) and merges its FID+SFI pairs
into the channel's SFI map, so SFI-addressed SEARCH/READ resolve without
the file's own FCP
- the learned relations are cached per DF for the session: the live trace
leaves DF_PHONEBOOK for DF_TELECOM (SELECT 7F10/6F06) and comes back, and
the DF change used to rebuild the map from the static table only, dropping
the PBR's pairs — the re-entry now merges the session cache
- verified on session 193: the SEARCH at 5.434 s (SFI 2) now resolves to
4f3a (EF_ADN), as do the later ones (31.562/253.475/279.874 s)
- tests: the DB-level case — a PBR read, an excursion to DF_TELECOM and back,
then an SFI-addressed SEARCH asserting the declared file; 538 Python +
76 Node tests
- PWA_VERSION/pyproject/version.py 2.7.8, SW cache simtrace-analyser-v88
catarrh
824405f936
