Background
CMD_WRITE currently fails fast and cleanly when the Piper Wyoming server can't be reached or stalls mid-stream: non-blocking connect + WaitSelect timeout (5s) on connect, SO_RCVTIMEO on a mid-stream stall, cleanup on every error path, and a non-zero io_Error returned on the IORequest. No hang, no Guru.
However, from the perspective of a user sitting at the Amiga (e.g. running the stock Say command), this looks silent — no speech, no crash, no indication that anything went wrong. Most callers don't surface io_Error to the user in any visible way.
Ask
Investigate whether there's a reasonable way to escalate a first-failure connectivity/timeout error to the user, e.g.:
- An async Intuition requester (
EasyRequest/AutoRequest) popped from the device's own task the first time a write fails, so the user gets some on-screen indication ("Could not reach TTS server at host:port").
- Consider whether this should be rate-limited (only first failure, or once per some interval) so a broken connection doesn't spam requesters if the caller retries
Say repeatedly.
- Consider whether this should be an opt-in prefs setting (e.g.
notify_on_failure) since some users may prefer purely silent/log-only failure, and popping a requester from a non-interactive/background context could be surprising or problematic (e.g. what public screen to attach to, whether the calling task's context is appropriate for Intuition calls).
- Note the device has no C globals/statics (see CLAUDE.md "NO C globals/statics in the device") — any "have we already notified" state needs to live in the per-open/task-allocated context, not a file-scope variable.
This is exploratory — the outcome may be "not worth the complexity" as much as it may be "implement it."
Background
CMD_WRITEcurrently fails fast and cleanly when the Piper Wyoming server can't be reached or stalls mid-stream: non-blocking connect +WaitSelecttimeout (5s) on connect,SO_RCVTIMEOon a mid-stream stall, cleanup on every error path, and a non-zeroio_Errorreturned on the IORequest. No hang, no Guru.However, from the perspective of a user sitting at the Amiga (e.g. running the stock
Saycommand), this looks silent — no speech, no crash, no indication that anything went wrong. Most callers don't surfaceio_Errorto the user in any visible way.Ask
Investigate whether there's a reasonable way to escalate a first-failure connectivity/timeout error to the user, e.g.:
EasyRequest/AutoRequest) popped from the device's own task the first time a write fails, so the user gets some on-screen indication ("Could not reach TTS server at host:port").Sayrepeatedly.notify_on_failure) since some users may prefer purely silent/log-only failure, and popping a requester from a non-interactive/background context could be surprising or problematic (e.g. what public screen to attach to, whether the calling task's context is appropriate for Intuition calls).This is exploratory — the outcome may be "not worth the complexity" as much as it may be "implement it."