You can close the tab now

The spinner has no memory

The export takes several minutes, and the person who requested it needs to close the tab. Can they? A spinner tells them something is happening now; it does not say whether the job survives a refresh, where the file will appear or how to find it tomorrow. Those answers belong to a durable job record. The waiting screen becomes useful when it shows that record, rather than making the open browser look responsible for keeping the work alive.

Start with what the requester needs to know: whether the export was accepted, whether leaving is safe, where the result will be and what stopping it would mean. A reliable worker can continue in the background while a forgetful page makes the service feel lost. Give the person somewhere to return to, so checking progress does not depend on preserving the original connection or trusting a spinner they can no longer see.

Consider a fictional inventory export containing 4,800 records. The application accepts the request and creates job E-61. The worker will fetch data, assemble a file and make it available to the authorised requester. Some records may be skipped under a documented rule. The job can finish after the browser closes. The screen should explain that actual contract rather than imply that keeping a tab open is part of the export algorithm.

HTTP 202 means accepted for processing, rather than completed. RFC 9110 describes the response as noncommittal and points towards a status monitor. For E-61, the application needs to preserve that distinction: acknowledge the durable job, expose its current state and announce completion only when the promised result is available. Acceptance is evidence that processing may continue, not that the export file already exists.

Give the job somewhere to live

Create a durable job identity and a status route the person can return to. Store who requested it, the relevant input snapshot or revision and the current lifecycle state. If the export is for a particular inventory view, the result should not quietly become a different view because somebody changes a filter after submission.

For E-61, queued can mean accepted but not started; completed must mean the promised result is available under the export’s stated rule. Add running, cancellation_requested, failed and cancelled as the lifecycle needs them. Decide what allows each transition before choosing its name. A worker can finish successfully while the file still needs uploading or a permission check. The status page should wait for that remaining work before offering completion.

The status page should retrieve the existing job rather than create another export on refresh. A separate “start another export” control can remain available where appropriate. Distinguishing observation from creation prevents an ordinary browser action from becoming an accidental workload generator. It also gives support a stable reference when the person reports a problem.

Access to both the job and its file needs authorisation; an opaque URL does not replace a permission check. The result also needs a stated availability period and an appropriate action after expiry. Keeping completion history while showing that the file has expired gives the person an accurate account of E-61 instead of a download control whose failure leaves its status unclear.

Progress needs a denominator it can defend

For E-61, suppose the worker has inspected 1,200 of a fixed 4,800-record snapshot. It can truthfully report 25% of records inspected. That does not establish 25% of elapsed time or 25% of the complete export effort. Some records may require extra work, and assembling or uploading the file may be a separate stage.

Use labels that describe the measured quantity. “1,200 of 4,800 records inspected” is often better than an unqualified progress bar. Show the current stage, last meaningful update and any known waiting reason. If the total is not yet known, say that the job is discovering records rather than presenting a percentage whose denominator will change beneath it.

Whether E-61 includes records added during processing is a product decision. A fixed snapshot keeps the denominator at 4,800; a moving population can be valid if its boundary is explained. Otherwise a decreasing percentage could reflect newly discovered work rather than lost progress. The status label should let the requester distinguish those interpretations without inferring the export's data contract from the movement of its bar.

If comparable completed jobs support a useful time range, show that range and say which jobs it describes. Without that history, a clear processing stage and a route back are enough to help the requester plan. Repeating about one minute for ten minutes asks them to keep revising a plan around a prediction the service does not have. The inspected-record count can be useful without pretending to measure the remaining time.

Cancellation is a request with an outcome

A cancel button should explain what can still be stopped. Before E-61 starts, cancellation might prevent all processing. During processing, the worker may need to observe the request at a checkpoint. During final publication, the file may become available before the cancellation takes effect. These races are part of the job contract.

After 1,200 records are inspected, a cancellation request leaves the outcome pending until the worker confirms it. Show cancellation_requested while it races final publication. If completion wins, explain that the export finished before cancellation took effect and apply the stated result policy. The requester may still be disappointed, but they can understand what happened. Calling it cancelled immediately would leave the interface describing a different job from the one still running.

For a read-only export, finishing unnecessary work might mainly consume resources. For an import that changes records, cancellation cannot usually undo changes already committed. The screen would need to report partial effects and any supported recovery route. A shared component should not promise “nothing will change” merely because its button has the same label on both kinds of job.

Cancellation, removing a list entry and deleting a result require different controls. Hiding E-61 does not stop its worker, and deleting the file cannot retract a copy already downloaded. Name each operation according to its effect and check permission where that effect occurs. The lifecycle record can then retain a truthful outcome even if the requester no longer wants the job or its result displayed.

Completion includes the inconvenient cases

A usable final screen should report what the export contains. If 4,790 records were exported and ten skipped, explain the skip rule and provide safe details for investigation. Do not silently convert “job completed” into “every requested record is present”. The completion contract can allow exclusions, but the result must make them visible.

After failure, preserve E-61's input boundary and last meaningful state. Decide whether a retry resumes that job or creates a related one, and make the choice visible. If yesterday's snapshot is no longer reproducible, regenerating against current inventory produces a different result. The failure route needs to explain that limitation before presenting another export as completion of the original accepted request.

Try the interruptions

Review a page refresh while queued, a browser close while running, a worker restart, a late cancellation and an expired download. These cases reveal whether the status page represents durable work or merely the life of a component in the browser. They also expose what a colleague can learn without opening a developer console.

Consider how often progress is announced as well as how often it changes. A constantly repeated status can interrupt someone using assistive technology. Make the current state readable on demand and reserve prominent announcements for meaningful transitions. Test the chosen behaviour with the supported tools rather than assuming that a visually quiet update is quiet for everyone.

Polling, server-sent events or another update mechanism can keep the page current. The transport is secondary to the state contract. An update connection can fail while the job continues; show that the view is stale and offer a refresh route rather than declaring the job failed. Keep status checks proportionate so a roomful of waiting browsers does not become a new load problem.

When the person returns tomorrow, the status route should open the same E-61 they requested. If the file has expired, say that beside its completed history; if work continues, show its current stage and last meaningful update. They can find out what happened without creating another export or treating the browser they closed as the last thing holding the first job together.