mirror of
https://github.com/agessaman/meshcore-bot.git
synced 2026-09-17 05:04:19 +00:00
Adam Gessaman
a9f10d4dce
Verifying a channel message against the RF cache only ever checked the row strategy 4 returned — the most recent packet heard. That assumes the RF log row and the decoded CHAN event for one reception arrive back to back with nothing in between. On a dense mesh they do not: a repeater's echo of the very same packet is routinely logged in the gap. The reporter's message was heard directly (SNR 13.25, 0 hops) and again via repeater f0 185 ms later (SNR 12.0, 1 hop). Both rows carry packet hash 392926C85DCB87D0, but the check saw only the echo, disagreed on path length and SNR, and left the route unresolved — so the bot withheld a path it had decoded correctly and answered "No path information available in current message". The reporter's own observation that MultiTest still reported paths is the tell: multitest reads recent_rf_data directly and never consults the match tag, so the radio data was there the whole time. The cache is now searched for the row the payload matches rather than testing just the newest one. #80's guarantee is unchanged — a route is still only ever attributed on a positive match, never on recency — so this widens where the check looks, not what it accepts. When more than one row matches they must resolve to a single non-empty packet hash, which is only true of receptions of one packet; two unrelated packets that happen to agree on all three fields stay a fallback. A debug line now names the case where the newest row was not the message's packet, so this failure mode is visible in logs rather than silent. Side effect worth knowing: SNR and RSSI now come from the message's own reception too. The reporter's message was logged at SNR 12.0 / RSSI -10, the echo's figures, when its actual reception was 13.25 / -32. Five tests cover it, including a reproduction built from the issue's log. Three fail on the current code; the other two pin behaviour the fix must not break — newest-wins among receptions of one packet, and scope_eligible_only still filtering the search so the scope correlation cannot be handed an ineligible row.