A request that runs out of time tells the member to try again, though its work may still finish #296

New Issue

2026-10-30T19:47:46Z

cgalo5758 commented

2026-10-30 19:47:46 +00:00

What happens

When a request runs past the console's 32-second request timeout, the console answers 503 with the plain text "Request timed out" (internal/middleware/timeout.go). For a request a page sends in the background, the page's error handler then shows its generic message, "Server error. Try again later." (internal/embeds/static/error-handler.js). A full page load shows the bare text on an unstyled page.

Neither answer says what the member most needs to know: the work may still finish. A plan change's Stripe calls, and the switch of a paused plan, keep running after the timeout, so the change can take effect after the member was told to try again, and a retry can repeat a move that is already under way.

What should happen

The timeout answer tells a background request that the outcome is not known yet and that reloading the page shows it, rather than inviting a retry. A full page load gets the console's styled error page with the same message. Both need new wording.

Where

internal/middleware/timeout.go; internal/embeds/static/error-handler.js; the error page templates.

Why it matters

A member who follows the advice can make the same plan change twice, or act on a plan that is about to change.

### What happens When a request runs past the console's 32-second request timeout, the console answers 503 with the plain text "Request timed out" (`internal/middleware/timeout.go`). For a request a page sends in the background, the page's error handler then shows its generic message, "Server error. Try again later." (`internal/embeds/static/error-handler.js`). A full page load shows the bare text on an unstyled page. Neither answer says what the member most needs to know: the work may still finish. A plan change's Stripe calls, and the switch of a paused plan, keep running after the timeout, so the change can take effect after the member was told to try again, and a retry can repeat a move that is already under way. ### What should happen The timeout answer tells a background request that the outcome is not known yet and that reloading the page shows it, rather than inviting a retry. A full page load gets the console's styled error page with the same message. Both need new wording. ### Where `internal/middleware/timeout.go`; `internal/embeds/static/error-handler.js`; the error page templates. ### Why it matters A member who follows the advice can make the same plan change twice, or act on a plan that is about to change.

cgalo5758 added the

kind

bug

area/member-ui area/ops labels 2026-10-30 19:47:46 +00:00

cgalo5758 commented

2026-10-31 00:22:18 +00:00

A second unknown outcome belongs to this question. When a member's plan change makes a write at Stripe and Stripe answers it with a server error (a status of 500 or above) before the member's request has ended, the console answers "We couldn't complete that change. Try again in a moment." although the write may have gone through. Stripe's event then brings the console's records up to date, and after a reload the member's page shows the change, for every change but a downgrade. The console records a downgrade only from Stripe's answer, so after a reload the page can show no downgrade that Stripe will still carry out at the renewal. That is an unknown outcome, the same as a timeout, and it does not reach the timeout answer. Whatever wording settles the unknown outcome of a timeout should cover it. The fix for #295 leaves this behaviour as it is.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiki-cafe/member-console#296