Mark pending channel messages sent on RESP_CODE_SENT#186
Mark pending channel messages sent on RESP_CODE_SENT#186Specter242 wants to merge 2 commits intozjs81:mainfrom
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d270683d25
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (_retryService != null) { | ||
| _retryService!.updateMessageFromSent(ackHash, timeoutMs); | ||
| } | ||
| _markMostRecentPendingChannelMessageSent(); |
There was a problem hiding this comment.
_handleMessageSent now calls _markMostRecentPendingChannelMessageSent() for every full RESP_CODE_SENT, but those responses are also used for direct messages. If a user has any pending outgoing channel message and then sends a direct message, the direct-message ACK will incorrectly flip that channel message to sent even though no channel send confirmation was received, producing false delivery state in the channel UI/storage.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch. Updated in 96fb9ca: channel pending→sent is now gated so it only runs when RESP_CODE_SENT was not matched to a direct message and there are no pending direct retries. This prevents direct-message ACKs from flipping channel state.
| if (_markMostRecentPendingChannelMessageSent()) { | ||
| return; |
There was a problem hiding this comment.
In the legacy fallback path (frame.length < 10), returning immediately after marking a pending channel message means the previous direct-message fallback loop is skipped whenever any channel message is pending. On older firmware/protocol variants that emit short RESP_CODE_SENT frames, this leaves outgoing direct messages stuck in pending as long as a channel pending message exists.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in 96fb9ca. I removed the early channel return from the short-frame fallback path; frame.length < 10 now preserves the original direct-message fallback loop so direct pending messages are still advanced on legacy short sent frames.
I need to switch to in progress as this is still not properly catching all acks. |
1 participant
Problem
Outgoing channel messages can remain in a pending state even after the app receives
RESP_CODE_SENT, especially in sparse/public-channel paths where echo timing is delayed.Solution
RESP_CODE_SENT, mark the most recent pending outgoing channel message assentScope
lib/connector/meshcore_connector.dartonlyValidation
flutter analyzepassesflutter testpassesCloses #185