Same is_available/render double-fetch bug as #17 exists in 4 more slide types #19

New issue

Closed

opened 2026-08-13 19:33:15 +00:00 by paulloth1 · 1 comment

paulloth1 commented

2026-08-13 19:33:15 +00:00

(Migrated from github.com)

Problem

#17 fixed this for rss.py, but the same pattern exists unfixed in four other slide types — each one's is_available() does a full network request to check reachability, and render() (called right after, if is_available returned True — see backend/rotation.py:139-159) does another full request for the same data:

backend/slides/mastodon.py: is_available() (line 30-33) calls url_ok(_timeline_url(...)); render() (line 36+) calls fetch_json(_timeline_url(...)) — same URL, fetched twice.
backend/slides/train.py: is_available() (line 7-10) calls url_ok(config["api_url"]); render() (line 13+) calls fetch_json(config["api_url"]) — same URL, twice.
backend/slides/api_status.py: is_available() (line 37-40) calls fetch_json(...) (a full fetch, not even a lightweight check); render() (line 43+) calls fetch_json(...) again with the same URL.
backend/slides/matrix.py: is_available() (line 20-23) calls url_ok(_messages_url(...)); render() (line 26+) calls fetch_json(_messages_url(...)) — same URL, twice.

(webcam.py is fine — its render() just embeds <img src> directly with no server-side fetch, so there's no duplication there.)

Every rotation step that reaches one of these 4 slide types makes 2 outbound requests to the same third-party API for no benefit — same root cause as #17.

Suggested fix

Apply the same fix used for rss.py in #17: simplify each is_available() to a cheap, network-free check (e.g. just confirm the required config fields are present/non-empty), and let render()'s existing "Unable to load ..." fallback text be the sole failure-surfacing path. Note the same tradeoff called out when #17 was fixed: a misconfigured/dead endpoint will occupy a full rotation interval showing an error message instead of being silently skipped — acceptable for the same reasons it was accepted there.

api_status.py is the worst offender since even its "availability check" does a full JSON fetch+parse rather than the lighter url_ok() the others use.

Where

backend/slides/mastodon.py:30-33, backend/slides/train.py:7-10, backend/slides/api_status.py:37-40, backend/slides/matrix.py:20-23

## Problem #17 fixed this for `rss.py`, but the same pattern exists unfixed in four other slide types — each one's `is_available()` does a full network request to check reachability, and `render()` (called right after, if `is_available` returned True — see `backend/rotation.py:139-159`) does another full request for the same data: - **`backend/slides/mastodon.py`**: `is_available()` (line 30-33) calls `url_ok(_timeline_url(...))`; `render()` (line 36+) calls `fetch_json(_timeline_url(...))` — same URL, fetched twice. - **`backend/slides/train.py`**: `is_available()` (line 7-10) calls `url_ok(config["api_url"])`; `render()` (line 13+) calls `fetch_json(config["api_url"])` — same URL, twice. - **`backend/slides/api_status.py`**: `is_available()` (line 37-40) calls `fetch_json(...)` (a full fetch, not even a lightweight check); `render()` (line 43+) calls `fetch_json(...)` again with the same URL. - **`backend/slides/matrix.py`**: `is_available()` (line 20-23) calls `url_ok(_messages_url(...))`; `render()` (line 26+) calls `fetch_json(_messages_url(...))` — same URL, twice. (`webcam.py` is fine — its `render()` just embeds `<img src>` directly with no server-side fetch, so there's no duplication there.) Every rotation step that reaches one of these 4 slide types makes 2 outbound requests to the same third-party API for no benefit — same root cause as #17. ## Suggested fix Apply the same fix used for `rss.py` in #17: simplify each `is_available()` to a cheap, network-free check (e.g. just confirm the required config fields are present/non-empty), and let `render()`'s existing "Unable to load ..." fallback text be the sole failure-surfacing path. Note the same tradeoff called out when #17 was fixed: a misconfigured/dead endpoint will occupy a full rotation interval showing an error message instead of being silently skipped — acceptable for the same reasons it was accepted there. `api_status.py` is the worst offender since even its "availability check" does a full JSON fetch+parse rather than the lighter `url_ok()` the others use. ## Where `backend/slides/mastodon.py:30-33`, `backend/slides/train.py:7-10`, `backend/slides/api_status.py:37-40`, `backend/slides/matrix.py:20-23`

paulloth1 commented

2026-08-13 19:39:06 +00:00

(Migrated from github.com)

Fixed and deployed. is_available() in mastodon.py, train.py, api_status.py, and matrix.py no longer makes a network call — each keeps its required-field guard but returns True after that, letting render()'s existing error fallback be the sole failure path. Verified all 4 backend services restarted cleanly and the admin/rotation endpoints still respond correctly.

Fixed and deployed. `is_available()` in mastodon.py, train.py, api_status.py, and matrix.py no longer makes a network call — each keeps its required-field guard but returns True after that, letting render()'s existing error fallback be the sole failure path. Verified all 4 backend services restarted cleanly and the admin/rotation endpoints still respond correctly.