Node hash size still shown as “varies” / mixed 1-byte and 2-byte for MeshCore v1.16.0 repeater configured with path.hash.mode=1

[Trixster-dk]

Description:
I am seeing a node being reported by CoreScope as having varying advert hash sizes, for example mixed 1-byte and 2-byte adverts, even though the node is running MeshCore repeater firmware v1.16.0 and is configured for 2-byte path hashes.

Node:
Name: DK_3400_RAK_TEST
Firmware: v1.16.0-07a3ca9, build 06-Jun-2026
Role: repeater
Config: path.hash.mode = 1
Expected hash size: 2-byte
Public key: [insert public key here]
Observed on multiple CoreScope/MQTT sites
Problem has persisted for about 7 days, so this does not appear to be only short-lived old history after a config change

CLI confirmation:
ver
v1.16.0-07a3ca9 (Build: 06-Jun-2026)
get path.hash.mode=1

Observed behavior:
CoreScope shows the node as having a 2-byte hash prefix, but also marks it as “varies” / mixed hash sizes. Packet history shows both 1-byte and 2-byte adverts for the same node.

Expected behavior:
If the latest valid non-zero-hop advert from this node is 2-byte, CoreScope should show the node as 2-byte, not “varies”, unless it can point to a recent valid 1-byte flood advert from the same public key.

Why this may be CoreScope-related:
This looks related to previous fixes:

#303: repeater hash stats not updating based on most recent advert
#341: latest advert should determine node hash size instead of historical mode
#493: zero-hop direct adverts should be skipped when checking node hash size

Question:
Could CoreScope still be including old historical adverts, direct zero-hop adverts, or stale per-node hash-size observations when deciding whether a node is “varies”?

[Kpa-clawbot]

Severity: P2 — Reporter-visible misclassification of a single node's hash mode.

Claim: unverifiable as-filed — issue body has Public key: [insert public key here] placeholder, so we can't query the actual node's history.

Code today:

• cmd/server/store.go:8447 computeNodeHashSizeInfo() — scans byPayloadType[4] adverts within a 7d FirstSeen cutoff, records every (pathByte>>6)+1 size into ni.Seq/ni.AllSizes.
• cmd/server/store.go:8489 — skips direct zero-hop adverts (routeType 2/3 with pathByte&0x3F == 0) — addresses fix: skip zero-hop adverts when checking node hash size #493.
• cmd/server/store.go:8519 — uses ni.Seq[len-1] as authoritative current hash size; flip-flop flag requires len(Seq)>=3 && len(AllSizes)>=2 && transitions>=2.
• public/nodes.js:681 renders “varies” when hash_size_inconsistent is true.

Findings:

• (house): The 7d cutoff is FirstSeen string-compare. If a non-zero-hop 1-byte advert was observed >7d ago but its FirstSeen got bumped to within the window (e.g. via late observer ingest, backfill, or FirstSeen being computed from MIN(observation.ts) for any observer including a stale one), it stays in the pool — explains "persisted 7 days" without a real flip-flop.
• (carmack): byPayloadType[4] iteration order is insertion order, not timestamp order. ni.Seq[len-1] ≠ "most recent advert" unless inserts are strictly chronological. On chunked cold-load or out-of-order MQTT ingest, "latest" picks wrong size — see v3.9.2 cold-load: reader p95 catastrophically degraded for 10-15 min after backgroundLoadComplete=true #1724-class lock/ordering risks.
• (meshcore): zero-hop transport adverts (routeType 3) skip uses pathByte&0x3F == 0 — but transport-flood (routeType 0) zero-hop is not skipped, and firmware can emit 1-byte placeholder path bytes there too.

Fix path: Cannot lock without the node's pubkey + raw advert hex from the operator's DB. Likely surface is cmd/server/store.go:8447-8538. Effort: M.

Dup check: searched "varies hash mixed 1-byte 2-byte" — related #303, #341, #493 (cited by reporter); no open dup.

Triage verdict: needs-operator-input

[Trixster-dk]

Thanks. The public key placeholder was my mistake.

Actual node public key:
36f6c7c73dfd265db996aeee25e1dc0cfe1ad4e5c1d6dd575325e3b241f4af78

CoreScope node page:
https://rf.rbit.se/#/nodes/36f6c7c73dfd265db996aeee25e1dc0cfe1ad4e5c1d6dd575325e3b241f4af78

The node is running MeshCore repeater v1.16.0-07a3ca9, and path.hash.mode is set to 1.

I do not run the rf.rbit.se CoreScope instance, so I do not have direct access to the database or raw advert hex.

Can you check the node history with the public key above, or let me know exactly what I should ask the rf.rbit.se operator to provide?

I am mainly trying to find out why CoreScope still shows this node as mixed/varies hash size.

[Kpa-clawbot]

Severity: P3 — single-node UX misclassification; not pipeline-affecting.

Claim: confirmed. rf.rbit.se /api/nodes/36f6c7c7… returns hash_size_inconsistent=true, hash_sizes_seen=[1,2], multi_byte_status=confirmed.

Code today: cmd/server/store.go:8447-8538 computeNodeHashSizeInfo() — collects sizes from non-zero-hop adverts within a 7d FirstSeen window; sets inconsistent when len(Seq)>=3 && len(AllSizes)>=2 && transitions>=2.

Evidence in node history: of 20 recent adverts for this pubkey, one on 2026-06-09T06:30:17Z has path_lengths={2} across 15 distinct observer paths → that's a genuine 1-byte flood advert, ~5 days old, well inside the 7d window. All other non-zero-hop adverts are 2-byte. So the "varies" verdict is factually correct given current heuristic — there really was a 1-byte advert 5d ago.

Findings:

• (house): The heuristic is right by its own definition — there was a 1-byte advert. The bug isn't false-positive logic; it's that operators who flip path.hash.mode=1 mid-flight stay flagged for 7 days. No way to say "trust the new config."
• (carmack): When multi_byte_status=confirmed AND the most-recent N adverts are all 2-byte, the "varies" flag becomes stale noise. Suggest decay: if last 3 non-zero-hop adverts agree, clear inconsistent regardless of older history.

Fix path: store.go:8519 — change flip-flop condition to weight recent adverts: e.g. if last3SameSize { inconsistent = false }. Effort: S. But: this is a behavior/policy change, not a bug fix — needs operator sign-off on the rule before code lands.

Dup check: none. Related #303/#341/#493 already cited.

Triage verdict: needs-operator-input