fix(#501): apply Gemini review, de-duplicate suppression logging
Three findings reviewed, two applied, one rejected on evidence. APPLIED. Suppression logging is de-duplicated. Device-info arrives on every connect, so a flapping radio would have emitted the same suppression line on each reconnect. It now logs once per distinct reason, and the memo clears when a gate opens or when per-radio state is cleared, so the next genuine suppression is still reported. Real, and exactly the flooding the project forbids. APPLIED, though not reachable today. The scope reply logged reply.scope!, which is safe only because parseNotifyScopeReply returns an ERROR reply when the scope code is unknown, so a non-error reply always carries a scope. That invariant lives in another file, so it is now checked at the boundary instead of asserted with a bang across it. The review rated this High on the theory that an unknown sub-code could reach the handler; it cannot, because the parser returns null for any sub-code it does not own and the dispatcher only forwards what it returned. Defect not reachable, guard still worth having. REJECTED. The review claimed the matrix reply log is unbounded because the wire count byte allows up to 255 rows, estimating 7.5 KB per line. The log is built from ButtonMatrix.assignments, a Map keyed by ButtonSequence, which has exactly four values, and the parser skips sequence codes it does not recognise rather than adding them. The map therefore holds at most four entries and the line is bounded at roughly 160 characters no matter what the device sends. The count byte cannot inflate it. Full suite 740 pass, analyze clean, format clean. Agent: CalmBay (session d14220d9)fix/580-caplog-partial
parent
69da28002f
commit
a57ec8f902
Loading…
Reference in new issue