wxa/wxalert replies can arrive as a single character (weatherAlert[0] applied to string returns) #136

New Issue

2026-10-05T01:25:26+02:00

adam commented

2026-10-05 01:25:26 +02:00

Summary

wxa / wxalert replies can reach the mesh user as a single character (e, or the first letter of an active alert) because handle_wxalert applies [0] to values that are plain strings.

Where

mesh_bot.py (handle_wxalert, present at v1.9.9.8 and current main):

if "wxalert" in message:
    # Detailed weather alert
    weatherAlert = getActiveWeatherAlertsDetailNOAA(str(location[0]), str(location[1]))
else:
    weatherAlert = getWeatherAlertsNOAA(str(location[0]), str(location[1]))

if my_settings.NO_ALERTS not in weatherAlert:
    weatherAlert = weatherAlert[0]
return weatherAlert

The weatherAlert[0] unwrap assumes the tuple return of getWeatherAlertsNOAA ((alerts, count)), but two reachable cases return a plain string:

Fetch failure (both commands) — getWeatherAlertsNOAA / getActiveWeatherAlertsDetailNOAA return ERROR_FETCHING_DATA ("error fetching data"). NO_ALERTS is not in that string, so [0] is applied → the user's radio shows the reply e.
wxalert (detailed) with active alerts — getActiveWeatherAlertsDetailNOAA returns the joined alert string (modules/locationdata.py, return alerts), so the user gets only its first character — e.g. W during a Winter Storm Warning. This is the worst case: the command works, the data is fetched, and an emergency-relevant reply is truncated to one letter.

Simulated the branch with the three return shapes to confirm: tuple → full text, "error fetching data" → e, "Winter Storm Warning ..." → W.

Suggested fix

Only unwrap when the value is actually a tuple:

if isinstance(weatherAlert, tuple):
    weatherAlert = weatherAlert[0]
return weatherAlert

(Or normalize both fetchers to one return shape.)

Context

Found during a reliability audit of the bot's data-source commands for a mesh deployment (fork: Nursedude/meshing-around). Happy to send a PR if useful.

## Summary `wxa` / `wxalert` replies can reach the mesh user as a **single character** (`e`, or the first letter of an active alert) because `handle_wxalert` applies `[0]` to values that are plain strings. ## Where `mesh_bot.py` (`handle_wxalert`, present at v1.9.9.8 and current `main`): ```python if "wxalert" in message: # Detailed weather alert weatherAlert = getActiveWeatherAlertsDetailNOAA(str(location[0]), str(location[1])) else: weatherAlert = getWeatherAlertsNOAA(str(location[0]), str(location[1])) if my_settings.NO_ALERTS not in weatherAlert: weatherAlert = weatherAlert[0] return weatherAlert ``` The `weatherAlert[0]` unwrap assumes the tuple return of `getWeatherAlertsNOAA` (`(alerts, count)`), but two reachable cases return a **plain string**: 1. **Fetch failure (both commands)** — `getWeatherAlertsNOAA` / `getActiveWeatherAlertsDetailNOAA` return `ERROR_FETCHING_DATA` (`"error fetching data"`). `NO_ALERTS` is not in that string, so `[0]` is applied → the user's radio shows the reply **`e`**. 2. **`wxalert` (detailed) with active alerts** — `getActiveWeatherAlertsDetailNOAA` returns the joined alert **string** (`modules/locationdata.py`, `return alerts`), so the user gets only its first character — e.g. **`W`** during a Winter Storm Warning. This is the worst case: the command works, the data is fetched, and an emergency-relevant reply is truncated to one letter. Simulated the branch with the three return shapes to confirm: tuple → full text, `"error fetching data"` → `e`, `"Winter Storm Warning ..."` → `W`. ## Suggested fix Only unwrap when the value is actually a tuple: ```python if isinstance(weatherAlert, tuple): weatherAlert = weatherAlert[0] return weatherAlert ``` (Or normalize both fetchers to one return shape.) ## Context Found during a reliability audit of the bot's data-source commands for a mesh deployment (fork: Nursedude/meshing-around). Happy to send a PR if useful.

adam closed this issue

2026-10-05 01:25:26 +02:00

adam commented

2026-10-05 01:25:27 +02:00

thanks dude, should be resolved holla if not!

thanks dude, should be resolved holla if not!

adam commented

2026-10-05 01:25:28 +02:00

holla BRAH--- meshing_around_meshforge been up for 2+ mo.
73

On Mon, Jul 6, 2026 at 2:07 PM Kelly @.***> wrote:

SpudGunMan left a comment (SpudGunMan/meshing-around#324)
https://github.com/SpudGunMan/meshing-around/issues/324#issuecomment-4898753682

thanks dude, should be resolved holla if not!

—
Reply to this email directly, view it on GitHub
https://github.com/SpudGunMan/meshing-around/issues/324?email_source=notifications&email_token=BKMRME7D6HZ7XHDLKDCMVQ35DQ5LPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZHA3TKMZWHAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4898753682,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BKMRME47H4PCIW2XWAQRDHD5DQ5LPAVCNFSNUABFKJSXA33TNF2G64TZHM4DCMZZHE2DCOJZHNEXG43VMU5TIOBSGIZTGNBYGU2KC5QC
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
It does not matter how slowly you go so long as you do not stop.
CONFUCIUS

holla BRAH--- meshing_around_meshforge been up for 2+ mo. 73 On Mon, Jul 6, 2026 at 2:07 PM Kelly ***@***.***> wrote: > *SpudGunMan* left a comment (SpudGunMan/meshing-around#324) > <https://github.com/SpudGunMan/meshing-around/issues/324#issuecomment-4898753682> > > thanks dude, should be resolved holla if not! > > — > Reply to this email directly, view it on GitHub > <https://github.com/SpudGunMan/meshing-around/issues/324?email_source=notifications&email_token=BKMRME7D6HZ7XHDLKDCMVQ35DQ5LPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBZHA3TKMZWHAZKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4898753682>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BKMRME47H4PCIW2XWAQRDHD5DQ5LPAVCNFSNUABFKJSXA33TNF2G64TZHM4DCMZZHE2DCOJZHNEXG43VMU5TIOBSGIZTGNBYGU2KC5QC> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> > -- It does not matter how slowly you go so long as you do not stop. CONFUCIUS

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: adam/meshing-around#136