Large form submit takes two minutes, then returns login expired: renew in advance or wait for a 401?

In most cases, renewal should not wait for a 401 to come back. If the 401 only arrives after the request has finished, it means those two minutes of computation and transfer are essentially wasted, and replay has to wait for another round. But if every request renews unconditionally before it is sent, short endpoints are slowed down by extra round trips. The basis for the decision is not habit; it is how long the request is expected to run and whether it can be safely replayed. Based on common 2026 delivery experience, a relatively stable split is: let second-level short requests trigger one replay on a 401; for minute-level long requests and upload endpoints, check the remaining validity period before starting — the typical range is to renew first when less than 5–10 minutes remain — and strictly limit replay to idempotent endpoints. As for changing the token validity period from 2 hours to 24 hours, that only changes the expiration time, not what happens at the moment of expiration.

Why is 'renew after receiving a 401' especially costly on long requests?

For short requests, encountering a 401 and replaying costs one extra round trip, and users barely notice; long requests are not like that. A two-minute submission, a several-hundred-megabyte upload, or a report export that takes minutes to produce all share a common trait: the duration may be much longer than the remaining lifetime of the credential. When the request is sent, the credential still has three minutes left; by the time it finishes, it has expired, the server rejects it at the authentication layer, and the computation already done has produced no result.

The bigger problem is the request body. For upload endpoints, the request body is a stream; once consumed, the frontend cannot simply 'replay' it in the browser, and the typical approach is to start the whole upload over. So the replay cost for such endpoints is not just time but also traffic and user patience, especially at sites with unstable uplink bandwidth.

• Idempotency: queries and exports produce no side effects when replayed once; creating an order or submitting an approval may generate two records if replayed, so an idempotency key is required before replay.
• Validation point: the server validates the credential state at the moment the request enters. If a long request expires in transit, the result depends on whether the gateway validates at the entrance or validates segment by segment. This must be checked against the actual request path, not assumed from memory.
• Concurrent renewal: several long requests discover expiration at the same time and all try to renew; the renewal credential is used up in one go, and the symptom is occasional logout.
• Replay count: limit replay to one attempt; if it fails, switch to a fallback. Otherwise a loop forms and turns a request that was merely slow into a server-wide overload.

In one delivery: upload reaches 80% and gets bounced back to the login page

Here is a concrete case. In one delivery there was a contract attachment upload feature; single files typically ranged from 100–300 MB, and the customer's uplink bandwidth was unstable. Feedback after launch was: when the upload reached 70–80%, the page jumped back to the login page; on return, the attachment was gone and had to be uploaded again from scratch. There were three constraints at the time: only one week left in the schedule, the backend chunked-upload API was already live and could not be changed, and the frontend upload component was a third-party library that exposed only a few hooks.

Our approach was not to touch the internals of the upload component but to wrap a layer around it: before starting an upload, check the locally recorded credential issue time; if the remaining time was below a threshold, renew silently first, then start the upload after renewal succeeds. The threshold was set according to the expected duration of a single upload, with an experience range of 5–10 minutes. If a chunk request encountered a 401 midway, it did not jump straight to login; instead, it first recorded the sequence numbers of successfully uploaded chunks, then resumed from the breakpoint after renewal. The cost was that this wrapper had to maintain chunk state separately, hook behavior had to be rechecked whenever the third-party component was upgraded, and the breakpoint information existed only in the current tab — if the user closed the page, they still had to start over.

The conclusion after this was: the renewal logic itself is not hard; what is hard is making every replay path know how far it can replay. To judge whether this layer is sufficient, do not look at whether there is a renewal API; look at how much the user has to redo after a long request fails.

Three trigger strategies compared

The three groups below are all experience ranges; adjust the specific values according to business sensitivity and platform rules. Do not treat them as standard answers.

• Strategy 1: Renew and replay only on a 401: frontend changes typically take 1–2 person-days; suitable for admin backends that are mainly second-level queries with idempotent endpoints; the cost is that long requests and upload endpoints waste a round.
• Strategy 2: Estimate the remaining validity period before starting a long request: changes typically take 3–5 person-days, depending on whether request wrapping is unified and whether uploads are chunked; suitable for systems with long forms, large files, and report exports; the cost is one extra renewal round trip, and the threshold must be set correctly, otherwise every request triggers renewal.
• Strategy 3: Set the validity period directly to 8–24 hours: almost zero changes; the cost is that the usable window after credential leakage also lengthens, forced logout and permission revocation after departure become harder to handle, and revocation logic for multi-device login becomes more convoluted.
• Checkable criterion 1: temporarily set the access credential validity to 1 minute, run a long request, and observe whether it is kicked out midway or completes after renewal. The two results correspond to completely different fixes.
• Checkable criterion 2: disconnect the network for 30 seconds and then restore it. A long request should appear as a retryable failure, not jump directly to the login page.
• Checkable criterion 3: open three tabs and upload small files at the same time, then count calls to the server's renewal endpoint. It should be close to one call, not three.

Applicable and non-applicable boundaries

This tiered approach suits web admin backends and mobile apps that have a login state, long page dwell time, and minute-level requests — for example, contract entry, batch import, attachment upload, and report export. The cases where it does not fit should also be stated clearly:

• Not necessary: pure intranet, single-user small ops tools where operations finish in seconds. Short-lived credentials plus normal logout are enough; adding predictive renewal would be over-engineering.
• Needs adjustment: for operations involving funds, approvals, or permission changes, even if the credential has not expired, require secondary verification before submission rather than using renewal to bypass the timeliness problem.
• Not applicable: legacy systems that are mainly server-side rendered and almost never send asynchronous requests have no trigger point for renewal; the focus should be on session configuration and logout redirects.
• Prevent: placing the renewal credential where page scripts can read it is like leaving a long-lived key at the front door; check the specific storage method against the platform's official documentation and security rules.
• Keep: no matter which strategy is chosen, save the form draft locally before logout and refill it after login. This step is the baseline for experience, not an optional item.

Common questions

If the access credential is valid for only 15 minutes, does that mean a long request cannot finish?

No. What cannot finish is the case where the credential expires in transit and there is no renewal channel at all. As long as you estimate the remaining time before starting or renew during the request, 15 minutes does not prevent a long request from completing.

If we renew once uniformly before submission, do we no longer need to handle 401s?

Not enough. It can still expire between successful renewal and request completion, and a network interruption will also return a failure. Predictive renewal and 401 replay are two complementary layers, not substitutes.

If a 401 occurs halfway through an upload, can the server continue receiving the remaining chunks?

It depends on whether the chunk API binds the upload session to the credential. A common approach is to resume with the original upload identifier after renewal, but API support and timeout windows must be checked against the API documentation; do not assume it works by default.

If renewal is put into the request interceptor, will long requests be blocked for a long time?

It adds one round trip, typically within a few hundred milliseconds. If the interceptor sends a renewal request for every request, change it to calculate the remaining time locally from the issue time and only actually send a renewal request when expiration is near.

Back to the opening question: extending the validity period is not something you cannot do, but it solves how often expiration happens, not what a long request should do at the moment of expiration. If people in your system are already complaining that uploads break halfway or report exports get kicked out midway, first use a test account to set the credential to 1 minute and run a long request. See whether it is kicked back to the login page or completes after renewal — the two results correspond to very different amounts of change.