Repository navigation
Web viewer: a read that times out returns an empty HTTP 500 and writes nothing to the service log #4276
Description
Activity
Ruled: how this gets built
- One error handler at the top of the web pipeline. It logs through the service's own logger, because the web host's logger writes nowhere by design.
- A statement timeout returns 503 with a JSON message: the store took too long to answer this read, try again in a moment. That covers SQLSTATE 57014 and a client-side command timeout. Any other failure returns 500 with a generic message, never the exception text.
- The JSON body reuses the shape the web endpoints already return for errors, so the viewer's existing error display can show it.
- One log line per failed request: a warning for a timeout, an error for anything else. It names the route, the elapsed time, the kind, and the exception type. There is no throttle.
- A browser that leaves the page is not an error and writes nothing.
- The
/api/read/*routes get a log line too, if they do not write one today. - Lite has no web host, so nothing changes there.
\U0001F916 Generated with Claude Code
- added 3 commits that reference this issue
on Sep 25, 2026
What happens
When a web viewer read runs past the viewer role's
statement_timeout(15 seconds), PostgreSQL cancels it. The endpoint returns HTTP 500 with an empty body, and the service log has no line for it. The only trace is in the PostgreSQL log:ERROR: canceling statement due to statement timeout.Seen on a field store on 2026-09-25:
GET /api/agreturned 500 after 15.65 seconds. Several page loads were reading/api/agat the same moment. A single warm call takes 1.4 to 2.2 seconds. The repeated page-load reads are fixed separately (#4189's count probe, #4228). This issue is about any web read that fails.Why there is no log line
DarlingWebHostServiceclears the web host's log providers on purpose, so request noise stays out of the service log. An endpoint that needs to log is meant to use the service logger thatMapAllreceives.But
/api/ag,/api/fleetand some other routes have no try/catch. Their exceptions reach ASP.NET Core's own error logging. That logging writes to the cleared providers, so the line is lost. The browser gets ASP.NET Core's default empty 500.What to change
/api/*route gets it without its own try/catch.RequestAborted) is not an error, and it is not logged./api/read/*routes write a log line too. They already catch exceptions and return an error envelope.PostgresExceptionreturns the JSON body and writes one log line./api/*route is mapped outside the handler.🤖 Generated with Claude Code
https://claude.ai/code/session_01TszxYhJJbTEh4LrZ56NYo3