From fb116905850be6a59fef62272e10cc99e362d0cb Mon Sep 17 00:00:00 2001 From: Jack Kingsman Date: Tue, 24 Feb 2026 20:47:59 -0800 Subject: [PATCH] Add errata note about continuous retry --- app/AGENTS.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/app/AGENTS.md b/app/AGENTS.md index 9e278fd..d3408bd 100644 --- a/app/AGENTS.md +++ b/app/AGENTS.md @@ -253,6 +253,10 @@ The MeshCore radio protocol encodes `sender_timestamp` as a 4-byte little-endian When our own outgoing DM is heard back via `RX_LOG_DATA` (self-echo, loopback), `_process_direct_message` passes `our_public_key=None` for the outgoing direction, disabling the outbound hash check in the decoder. The decoder's inbound check (`src_hash == their_first_byte`) fails because the source is us, not the contact — so decryption returns `None`. This is by design: outgoing DMs are stored directly by the send endpoint, so no message is lost. +### Infinite setup retry on connection monitor + +When `post_connect_setup()` fails (e.g. `export_and_store_private_key` raises `RuntimeError` because the radio didn't respond), `_setup_complete` is never set to `True`. The connection monitor sees `connected and not setup_complete` and retries every 5 seconds — indefinitely. This is intentional: the radio may be rebooting, waking from sleep, or otherwise temporarily unresponsive. We keep retrying so that setup completes automatically once the radio becomes available, without requiring manual intervention. + ### Contact lat/lon 0.0 vs NULL MeshCore uses `0.0` as the sentinel for "no GPS coordinates" (see `models.py` `to_radio_dict`). The upsert SQL uses `COALESCE(excluded.lat, contacts.lat)`, which preserves existing values when the new value is `NULL` — but `0.0` is not `NULL`, so it overwrites previously valid coordinates. This is intentional: we always want the most recent location data. If a device stops broadcasting GPS, the old coordinates are presumably stale/wrong, so overwriting with "not available" (`0.0`) is the correct behavior.