adam/Remote-Terminal-for-MeshCore
1
0
Fork 0
mirror of https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git synced 2026-08-08 09:43:03 +02:00
Code Issues Packages Projects Releases Wiki Activity

Do better DM retry to align with stndard firmware retry (but so that we can track the acks). Closes #73.

Browse Source
This commit is contained in:
Jack Kingsman
2026-03-17 18:12:07 -07:00
parent d5b8f7d462
commit 020acbda02
10 changed files with 474 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
app/AGENTS.md
+4
View File
@@ -118,6 +118,10 @@ app/
- `services/dm_ingest.py` is the one place that should decide fallback-context resolution, DM dedup/reconciliation, and packet-linked vs. content-based storage behavior.
- `CONTACT_MSG_RECV` is a fallback path, not a parallel source of truth. If you change DM storage behavior, trace both `event_handlers.py` and `packet_processor.py`.
- DM ACK tracking is an in-memory pending/buffered map in `services/dm_ack_tracker.py`, with periodic expiry from `radio_sync.py`.
- Outgoing DMs send once inline, store/broadcast immediately after the first successful `MSG_SENT`, then may retry up to 2 more times in the background if still unacked.
- DM retry timing follows the firmware-provided `suggested_timeout` from `PACKET_MSG_SENT`; do not replace it with a fixed app timeout unless you intentionally want more aggressive duplicate-prone retries.
- The final DM retry is intentionally sent as flood via `reset_path(...)`, even when a routing override exists.
- DM ACK state is terminal on first ACK. Retry attempts may register multiple expected ACK codes for the same message, but sibling pending codes are cleared once one ACK wins so a DM should not accrue multiple delivery confirmations from retries.
### Echo/repeat dedup