Operator errors point to the server logs but give no reference to find the line by #239

New Issue

2026-10-18T19:02:07Z

cgalo5758 commented

2026-10-18 19:02:07 +00:00

What a person cannot do today

When an operator page fails, its error often ends with "Details are in the server logs." or "see server logs". There are 30 such sentences in 10 files. An operator who cannot read the server's logs has nothing to pass on to the person who can.

That person cannot find the line either, except by time and wording. The handlers log their errors through h.Logger (192 calls under internal/server/), and those lines do not carry the request id. Only the access-log line that the logging middleware writes carries it.

What they should be able to do

Each such error shows a reference, and the error's log line carries the same reference. The operator hands the reference to whoever runs the server, and that person finds the line by searching for it:

Failed to save the settings. Reference: 0199f3a2-6c1e-7d40-9b1a-2f6c8e5d4a31

The request id already exists. The RequestID middleware puts it on the request's context and in the X-Request-ID response header, and the Logging middleware stores a logger carrying request_id in the context, which logging.FromContext returns. The handlers do not use that logger.

Two points to settle in the fix:

RequestID accepts any X-Request-ID the client sends, of any length. A reference shown on the page should be one the server generated or validated, so a client cannot choose what the page prints or point the search at other requests' lines.
Errors written outside a request (workflows, background work) need a reference of their own, such as the id of the record the work belongs to.

The readouts #187 adds for plan changes use this form from the start: the change's id under the list of organizations it could not move, and the request's id when Retry fails.

Why it matters

The sentence tells an operator that the cause is recorded somewhere they cannot see and gives them nothing to act on, and it gives whoever reads the logs no way to tell one failure from another in the same minute.

Where

internal/server/operator_*.go, internal/integrations/discourse/web/operator.go, internal/middleware/requestid.go, internal/middleware/logging.go, internal/logging/logging.go

Done when

No operator-facing error says "Details are in the server logs" or "see server logs". Each one shows a reference instead, a test finds that reference in the error's log line, and no page prints a client-supplied value as the reference.

### What a person cannot do today When an operator page fails, its error often ends with "Details are in the server logs." or "see server logs". There are 30 such sentences in 10 files. An operator who cannot read the server's logs has nothing to pass on to the person who can. That person cannot find the line either, except by time and wording. The handlers log their errors through `h.Logger` (192 calls under `internal/server/`), and those lines do not carry the request id. Only the access-log line that the logging middleware writes carries it. ### What they should be able to do Each such error shows a reference, and the error's log line carries the same reference. The operator hands the reference to whoever runs the server, and that person finds the line by searching for it: > Failed to save the settings. Reference: 0199f3a2-6c1e-7d40-9b1a-2f6c8e5d4a31 The request id already exists. The `RequestID` middleware puts it on the request's context and in the `X-Request-ID` response header, and the `Logging` middleware stores a logger carrying `request_id` in the context, which `logging.FromContext` returns. The handlers do not use that logger. Two points to settle in the fix: - `RequestID` accepts any `X-Request-ID` the client sends, of any length. A reference shown on the page should be one the server generated or validated, so a client cannot choose what the page prints or point the search at other requests' lines. - Errors written outside a request (workflows, background work) need a reference of their own, such as the id of the record the work belongs to. The readouts #187 adds for plan changes use this form from the start: the change's id under the list of organizations it could not move, and the request's id when Retry fails. ### Why it matters The sentence tells an operator that the cause is recorded somewhere they cannot see and gives them nothing to act on, and it gives whoever reads the logs no way to tell one failure from another in the same minute. ### Where `internal/server/operator_*.go`, `internal/integrations/discourse/web/operator.go`, `internal/middleware/requestid.go`, `internal/middleware/logging.go`, `internal/logging/logging.go` ### Done when No operator-facing error says "Details are in the server logs" or "see server logs". Each one shows a reference instead, a test finds that reference in the error's log line, and no page prints a client-supplied value as the reference.

cgalo5758 added the

kind

enhancement

area/operator-ui area/ops labels 2026-10-18 19:02:07 +00:00

cgalo5758 referenced this issue

2026-10-20 08:47:44 +00:00

Plan-wide changes to ladders and defaults run inside HTTP handlers, each with its own transaction shape #187

cgalo5758 commented

2026-10-20 14:03:50 +00:00

#187's sentences already carry a reference: the tier add, the tier delete, the tier removal and its preview, the reorder's preview and the default change, logged through the request's logger with the same id. So this issue's list keeps only the console's other sentences: 16 that still end "Details are in the server logs." or "see server logs", in 9 files. Two plan-act failures answer without a reference and without pointing to the logs: the tier removal's "Failed to remove the tier; nothing was changed." and the reorder's "Failed to reorder tiers.". They belong on this list too.

cgalo5758 referenced this issue from a commit

2026-10-20 14:04:41 +00:00

Tick the landing tasks of the plan-act obligations change

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#239