Alan-Jowett / sonde / 23819205766

82%

push

github

fix(node): recover from stale COMMAND frames during chunk transfer (#609)

* fix(node): recover from stale COMMAND frames during chunk transfer

When WAKE retries produce duplicate COMMAND responses from the gateway,
the stale frames sit in the ESP-NOW receive ring buffer.  The first
\get_chunk_with_retry\ call then receives a COMMAND frame (msg_type
mismatch) instead of the expected CHUNK response.  Previously every
stale frame consumed a retry attempt, exhausting all 4 attempts and
producing \ChunkTransferFailed { chunk_index: 0 }\.

Fix: when \get_chunk_with_retry\ receives an \UnexpectedMsgType\ error,
immediately re-read the transport instead of consuming a retry attempt.
This lets the real CHUNK response (queued behind the stale COMMAND) be
found without wasting the retry budget.

Also adds a WARN log in the gateway's \handle_get_chunk\ when a
GET_CHUNK is discarded because the session is not in \ChunkedTransfer\
state — previously this was a silent discard with zero logging, making
the failure invisible to operators.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* docs: specify stale frame handling during chunk transfer

Adds protocol.md §8.1 defining that stale frames with wrong \msg_type\
received during chunk transfer (e.g. duplicate COMMAND from WAKE
retries) MUST be discarded without consuming a retry attempt.

Updates:
- protocol.md §8: new §8.1 \Stale frame handling during chunk transfer\
- node-requirements.md ND-0701: adds AC4 (stale frame skip)
- node-design.md §4.3: adds stale frame note + pseudocode update
- node-validation.md: adds T-N803, updates traceability matrix

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* fix(node): drain all stale frames in chunk transfer loop

Address review feedback:
- Loop on \UnexpectedMsgType\ to drain multiple stale COMMAND frames
  (not just one), preventing seq mismatch on subsequent retries.
- Strengthen test: queue 3 stale COMMANDs (exceeding ret... (continued)

83 of 88 new or added lines in 2 files covered. (94.32%)

23623 of 27734 relevant lines covered (85.18%)

152.93 hits per line