Restart MSP over telemetry reply framing when a reply is discarded

[Raffi1202]

Problem

MSPv1 replies sent over CRSF telemetry arrive without the function byte: after the length byte the payload follows directly (#10667, captured on INAV 8.0.0). The receiving side cannot tell which request a reply belongs to and parses the payload at the wrong offset.

Cause

On maintenance-10.x the v1 reply header already contains the function byte (src/main/telemetry/msp_shared.c:229), but the same symptom is still produced by stale reply state. headerSent is a function-local static in sendMspReply() (msp_shared.c:209) and is cleared only after the last chunk (:261). When a new request arrives while a reply is still being sent, handleMspFrame() discards that reply through initSharedMsp() (:119-125, :66-77), which does not touch headerSent. The first chunk of the next reply then takes the continuation branch (:237): status byte only, no size, no function byte. Both transports reach this: SmartPort passes every incoming MSP payload to handleMspFrame() while a reply is pending (smartport.c:450), and CRSF drains several queued requests in one loop (crsf.c:128-136).

Change

Moves the flag to file scope as replyHeaderSent and clears it in initSharedMsp(), so a reply that follows a discarded one starts with a full header again. Changes the chunk test at msp_shared.c:244 from >= to >, so a payload that exactly fills the frame is sent as the last chunk instead of being followed by a frame that holds only a continuation status byte.

Test

Not run on hardware or SITL. Cause verified by reading msp_shared.c:209-261, crsf.c:128-136 and smartport.c:450 on maintenance-10.x; src/test/ has no test that references msp_shared.c.

Flash / RAM

Not measured yet. The upstream firmware CI has not been released for this PR, so no size report exists.

Docs

No documentation change needed: nothing under docs/ describes the MSP-over-telemetry frame layout or chunking (checked docs/Telemetry.md, docs/Rx.md, docs/development/msp/).

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Restart MSP telemetry reply framing after discarded replies

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Resets reply-header state whenever a new request discards an in-flight telemetry reply.
• Restores complete MSPv1 and MSPv2 headers on the replacement reply's first chunk.
• Eliminates status-only trailing frames when payload data exactly fills the current chunk.

Diagram

graph TD
  A["Telemetry Request"] --> B["Handle Frame"] --> C["Reset Reply State"] --> D["Process Request"] --> E["Build Reply Chunk"] --> F{"More Than Capacity?"}
  F -->|Yes| G["Continuation Chunk"] --> E
  F -->|No| H["Final Chunk"]

Loading

High-Level Assessment

The minimal module-scoped state fix is appropriate because initialization is the lifecycle boundary that discards pending replies. Keeping the flag function-local could not support reset from initSharedMsp(), while introducing a new reply context object would add unnecessary structural churn for this isolated state.

Files changed (1) +7 / -5

Bug fix (1) +7 / -5

msp_shared.cReset reply framing state and remove empty trailing chunks +7/-5

Reset reply framing state and remove empty trailing chunks

• Moves the reply-header flag to module scope so initSharedMsp() can clear it whenever an in-flight response is discarded. It also treats an exact payload fit as the final chunk, preventing a subsequent status-only telemetry frame.

src/main/telemetry/msp_shared.c

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can switch off images and animations for a plain-text comment

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗