Potential concurrency race on some targets

[robekl]

Hi. I asked an ai to analyze some things, and it came up with this. Is this worth pursuing?

Summary

NextHopRouter::pending appears to be accessed from multiple execution contexts without synchronization.

pending is a std::unordered_map:

• src/mesh/NextHopRouter.h:98

It is mutated in:

• startRetransmission() at src/mesh/NextHopRouter.cpp:249
• stopRetransmission() at src/mesh/NextHopRouter.cpp:217

It is iterated/erased in:

• doRetransmissions() at src/mesh/NextHopRouter.cpp:265

I do not see locking around these operations.

---

Confirmed concurrent-risk builds

1) ARCH_NRF52 with BLE enabled

nRF52 BLE write callback calls PhoneAPI::handleToRadio() directly in BLE context:

• src/platform/nrf52/NRF52Bluetooth.cpp:158
• src/platform/nrf52/NRF52Bluetooth.cpp:164

That path reaches:

• MeshService::handleToRadio() src/mesh/MeshService.cpp:177
• MeshService::sendToMesh() src/mesh/MeshService.cpp:245
• router->sendLocal() src/mesh/MeshService.cpp:251

At the same time, router retransmissions are processed in router/main scheduler path:

• NextHopRouter::runOnce() src/mesh/NextHopRouter.h:77
• doRetransmissions() src/mesh/NextHopRouter.cpp:265
• scheduler loop src/main.cpp:1189

This appears to permit concurrent access to pending.

2) ARCH_ESP32 when AudioModule is enabled (USE_SX1280 and !MESHTASTIC_EXCLUDE_AUDIO)

AudioModule creates a separate FreeRTOS task:

• src/modules/esp32/AudioModule.cpp:115

That task sends packets:

• run_codec2 calls sendPayload() src/modules/esp32/AudioModule.cpp:65
• sendPayload() calls service->sendToMesh() src/modules/esp32/AudioModule.cpp:268

Again, this reaches router->sendLocal() while router thread may run doRetransmissions().

---

Notes

• ESP32 NimBLE path seems intentionally marshaled to main task and may not have this issue:
  • src/nimble/NimbleBluetooth.cpp:407
  • src/nimble/NimbleBluetooth.cpp:166
  • src/nimble/NimbleBluetooth.cpp:305

So the ESP32 confirmed risk seems tied to additional RTOS tasks (e.g. AudioModule), not necessarily NimBLE ToRadio handling.

---

Potential impact

If this is valid, possible symptoms could include:

• intermittent retransmission state corruption
• dropped/extra retransmissions
• occasional hard-to-reproduce instability under traffic

---

Questions

1. Is there an existing single-threading guarantee for all calls that can touch retransmission state that I missed?
2. Would maintainers prefer:
   • a mutex around pending access, or
   • marshaling all router send/retransmission mutations onto one execution context?
3. Are there known bugs/crashes that might correlate with this path?

---

Prompt used to generate similar analysis

Review Meshtastic firmware routing code for thread concurrency hazards around retransmission state.
Focus on NextHopRouter::pending access paths and determine whether accesses can occur concurrently across target builds.