From 0826030f1c74ce6567f7a921ca75943c6be9eb76 Mon Sep 17 00:00:00 2001 From: Jack Kingsman Date: Tue, 24 Feb 2026 20:49:22 -0800 Subject: [PATCH] Add errata about 200 return for deletion of nonexistent channel --- app/AGENTS.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/app/AGENTS.md b/app/AGENTS.md index d3408bd..570d139 100644 --- a/app/AGENTS.md +++ b/app/AGENTS.md @@ -257,6 +257,10 @@ When our own outgoing DM is heard back via `RX_LOG_DATA` (self-echo, loopback), 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. +### DELETE channel returns 200 for non-existent keys + +`DELETE /api/channels/{key}` returns `{"status": "ok"}` even if the key didn't exist. This is intentional — the postcondition is "channel doesn't exist," which is satisfied regardless of whether it existed before. No 404 needed. + ### 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.