rick/LEDMatrix
1
0
Fork 0
mirror of https://github.com/ChuckBuilds/LEDMatrix.git synced 2026-10-06 15:25:08 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix(web): a refused on-demand start leaves no request in the mailbox

Browse Source 
POST /api/v3/display/on-demand/start delivered the request (control
socket, else the file mailbox) before it checked the display service.
With the service stopped the socket is absent, so the request went to the
mailbox; the route then answered 400 "Display service is not running"
when start_service was off, or 500 "Failed to start display service" when
the start failed. The display reads that mailbox with max_age=3600 and
never checks a request's timestamp, so the next time it was started it
ran the refused request, pinned if asked.

The service is now checked before anything is delivered, and nothing is
posted when start_service is off and the service is down. When the start
itself fails, the request is withdrawn from the mailbox, but only while
the mailbox still holds this request_id (the compare-before-delete the
display's _consume_on_demand_request uses), so a newer request posted in
the meantime is left for the display.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Chuck
2026-10-03 20:52:39 -04:00
co-authored by Claude Opus 5.5
parent a025f9897f
commit cdaeb3855d
3 changed files with 104 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+10
View File
@@ -557,6 +557,16 @@ policies are unchanged.
turning a category on or off in of-the-day always failed. The params now
reach the wrapper on its stdin; the script still receives them as JSON on
its own stdin, as before.
- An on-demand request that `/api/v3/display/on-demand/start` refuses no
longer runs later. The route posted the request to the display's mailbox
before checking the service, and the display reads that mailbox for an
hour without looking at a request's age. So with "Start display service"
unticked and the display stopped, the answer was "Display service is not
running", yet the next time the display was started it ran that plugin,
pinned if the request said so. The same happened after "Failed to start
display service". The route now checks the service first and posts
nothing when it refuses, and a request it posted before a failed start is
taken back out of the mailbox, unless a newer one has replaced it.
- The display schedule turns the panel off at exactly the end time. A window
now runs from its start time up to, but not including, its end time: with
07:00-23:00 the panel is on at 07:00 and off at 23:00. Before, the end