[Bug]: Text message delivery ACK/NAK silently dropped over BLE when phone MQTT proxy is active on a busy channel (2.8.0)

[ygeshors]

Contact Details

ygeshors@gmail.com

Checklist

• I am able to reproduce the bug with the latest version.

• I have updated to the latest Alpha firmware, and am able to reproduce the bug. Many issues are fixed quickly in alpha before the general beta release.

• I made sure that there are no existing OPEN or CLOSED issues which I could contribute my information to.

• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.

• This issue contains only one bug.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

• I actually read this list, and should be taken seriously.

Affected app version

2.8.0 (29321705)

Affected Android version

Android 16 - Xiaomi HyperOs

Affected phone model

Redmi Note 15 G

Affected node model

Heltec V3

Affected node firmware version

2.8.0.6eac181

Steps to reproduce the bug

1. Node config: EU_868 region, LongFast modem preset, Wi-Fi OFF, Bluetooth ON,
   MQTT enabled with proxy_to_client_enabled=true, broker mqtt.meshtastic.org,
   downlink enabled on LongFast channel.
2. On the phone, connect to the node via BLE, then enable the app's local
   "MQTT proxy on this phone" toggle (Settings > Radio Configuration > MQTT).
   Let it run for 1-2 minutes so downlink traffic from the public LongFast
   channel accumulates.
3. Send a text message on LongFast from the Android app.
4. Observe the message status.
5. For comparison: disable the phone-local "MQTT proxy on this phone" toggle
   only (no device config change, no reboot), then repeat step 3.
6. For comparison: enable Wi-Fi on the node instead of BLE
   (proxy_to_client_enabled=false), then repeat step 3.

Actual behavior

With BLE + phone-local MQTT proxy active on a busy LongFast channel, the
sent message stays at "Sending..." (ENROUTE) indefinitely — observed 10+
minutes with no resolution, no error, no delivery confirmation.
With the phone-local MQTT proxy toggle disabled (step 5), the same message
either delivers normally or receives an explicit "Failed to deliver to
mesh" — never hangs silently.
With Wi-Fi instead of BLE (step 6), the message always resolves correctly.

Expected behavior

The message should either deliver/confirm normally, or — if delivery
confirmation cannot reach the phone — the app should surface a clear
failure/timeout state rather than leaving the message in an indefinite
"Sending..." state with no feedback.

Screenshots/Screen recordings

Relevant log output

No adb logcat captured yet. This report is based on source code analysis
(Meshtastic-Android v2.8.0 and firmware @ HEAD 2.8.0-dev) — see "Root cause"
analysis below. Debug Panel export (App > Settings > Advanced > Debug Panel
> Export all) available on request if a maintainer needs it — happy to
capture it during a fresh repro if useful.

Additional information

• Phone battery optimization: set to "No restrictions" for the Meshtastic
  app (Xiaomi HyperOS is known to be aggressive with background BLE).
• Root cause analysis and suspected mechanism (queue saturation +
  optimistic ENROUTE status), plus related prior reports, detailed below.

[jamesarich]

Thanks for this — the underlying gap you're describing is real: ENROUTE is set optimistically before firmware confirmation, and in 2.8.0 there was no absolute timeout if the routing ACK/NAK never came back, so a message could sit at "Sending..." indefinitely.

That was fixed shortly after this was filed, in #6630 (SEND_ACK_TIMEOUT, 5 min, with automatic retry into a retryable failure state), first shipped in 2.8.1-internal.2, with further hardening in #6716. You were on 2.8.0, which predates the fix.

MQTT-proxy traffic doesn't saturate the send queue directly (it bypasses that FIFO), but it does share the same BLE write semaphore/mutex as regular sends, so heavy proxy traffic on a busy channel could plausibly delay the ACK/NAK enough to hit the old unbounded-wait behavior — a real trigger, just one layer lower than the queue you pointed at.

Could you retest on 2.8.1+ (or a current snapshot)? If it still hangs indefinitely with the timeout in place, that's a new bug worth its own report; otherwise this should be resolved.