Rotation-owner forwarding calls have no error handling — owner process being down 500s the other 3 ports #12

New issue

Closed

opened 2026-07-28 21:40:42 +00:00 by paulloth1 · 1 comment

paulloth1 commented

2026-07-28 21:40:42 +00:00

(Migrated from github.com)

Problem

Following the fix for #1, only the kiosk-internal process (`backend.service`, `127.0.0.1:8081`) runs the rotation loop; the other three processes (ports 80/443/8080) forward `GET /api/slide/current` and `POST /admin/slides/{id}/view-now` to it over loopback HTTP (`backend/app.py`).

Neither forwarding call has any error handling around the `httpx` request. If the owner process is ever down (restarting, crashed — e.g. due to #11), these calls raise an unhandled `httpx.ConnectError`/`TimeoutException`, which FastAPI turns into a raw, unfriendly 500 response instead of a graceful fallback. For `view-now` specifically, this also breaks the expected redirect-back-to-admin flow.

This is a new single point of failure introduced by centralizing rotation state in one process — a reasonable trade-off for correctness (see #1), but the failure mode should degrade gracefully rather than 500.

Suggested fix

Wrap both forwarding calls in a try/except for `httpx.HTTPError`, and on failure either:

for `/api/slide/current`: return a clear "rotation owner unreachable" JSON response (e.g. `{"id": null, "html": ..., "error": "..."}`) instead of a 500, so the display/admin JS's existing "keep showing whatever's on screen" fallback behavior kicks in cleanly, or
for `view-now`: still redirect back to `/` (possibly with a flash message) instead of raising.

## Problem Following the fix for #1, only the kiosk-internal process (\`backend.service\`, \`127.0.0.1:8081\`) runs the rotation loop; the other three processes (ports 80/443/8080) forward \`GET /api/slide/current\` and \`POST /admin/slides/{id}/view-now\` to it over loopback HTTP (\`backend/app.py\`). Neither forwarding call has any error handling around the \`httpx\` request. If the owner process is ever down (restarting, crashed — e.g. due to #11), these calls raise an unhandled \`httpx.ConnectError\`/\`TimeoutException\`, which FastAPI turns into a raw, unfriendly 500 response instead of a graceful fallback. For \`view-now\` specifically, this also breaks the expected redirect-back-to-admin flow. This is a new single point of failure introduced by centralizing rotation state in one process — a reasonable trade-off for correctness (see #1), but the failure mode should degrade gracefully rather than 500. ## Suggested fix Wrap both forwarding calls in a try/except for \`httpx.HTTPError\`, and on failure either: - for \`/api/slide/current\`: return a clear "rotation owner unreachable" JSON response (e.g. \`{"id": null, "html": ..., "error": "..."}\`) instead of a 500, so the display/admin JS's existing "keep showing whatever's on screen" fallback behavior kicks in cleanly, or - for \`view-now\`: still redirect back to \`/\` (possibly with a flash message) instead of raising.

paulloth1 commented

2026-07-28 21:43:34 +00:00

(Migrated from github.com)

Fixed in 73f0db2: both forwarding calls (/api/slide/current and view-now) now catch httpx.HTTPError. The slide/current fallback returns a clear 'Rotation owner unreachable' placeholder instead of a raw 500; view-now still redirects back to / instead of raising.

Fixed in 73f0db2: both forwarding calls (/api/slide/current and view-now) now catch httpx.HTTPError. The slide/current fallback returns a clear 'Rotation owner unreachable' placeholder instead of a raw 500; view-now still redirects back to / instead of raising.