Large report exports keep timing out: what should a background export job deliver?
A background export needs a traceable job, a reproducible data boundary and explicit outcomes for cancellation, failure and changing download permissions.
On this page5 sections
When large report exports repeatedly time out, a background job should provide more than a message saying that processing has started. Deliver a persistent job identifier, a status that users can revisit, an agreed data cutoff, failure handling and controlled downloads. Closing the page should not lose the job, and repeating a request should not silently create additional work. Acceptance and file completion are separate outcomes. Moving work into the background changes how users wait; it does not automatically fix slow queries, inconsistent data or excessive access.
Start with one report that people actually use
Choose an existing business report and record its filters, output columns, authorized data scope, file format, representative volume and busiest operating period. Establish why people need the file: checking transaction details, keeping a record or performing further calculations. Those purposes affect precision, file splitting and retention. “Export everything” is not a sufficient requirement.
Include these decisions in the reporting scope of custom software development (Chinese). Establish the threshold for background processing and the permitted number of simultaneous jobs through testing with agreed data in the intended environment. A simple export button can still represent expensive processing.
Give every job state an actionable meaning
| State | What the user knows | Acceptance evidence |
|---|---|---|
| Accepted or queued | A job exists and can be revisited | Its identifier survives refresh and navigation |
| Running | The current stage and last update | No invented percentage when total work is unknown |
| Cancellation requested or cancelled | Whether stopping is pending or confirmed | Residual files are handled under the agreed policy |
| Failed, completed or expired | A reason, a result or a way to request another export | A missing file is never presented as downloadable |
The Microsoft asynchronous request-reply pattern separates acceptance, status retrieval and the final result. It also describes cancellation as a request that the back end must process before updating the state. Other implementations are possible, but the displayed outcome must correspond to something that actually happened.
Decide what happens when the data changes during export
Suppose an order is added while the export is queued and a refund is recorded while it runs. Agree whether the file represents submission time, execution start or a defined business closing point. Saving filter values does not preserve a snapshot of the underlying records. Repeatedly reading current data in batches can produce a file containing several different moments.
If reproducibility matters, ask the development team to explain its snapshot, batch or other consistency mechanism and the associated cost. If a source API cannot provide a common cutoff, disclose the extraction interval and limitations in the file or job record. Do not label it a submission-time snapshot without supporting evidence. Test with records deliberately changed during processing, and compare both the detail rows and totals.
Separate duplicate requests from intentional reruns
A lost network response can leave the user uncertain even though the server accepted the export. Repeating that submission should recover the original job. A deliberate request to export the latest data may legitimately create another job. Neither merging identical filters forever nor creating work for every browser retry is a suitable default.
Agree the deduplication scope, its duration, how a failed job is reopened and how related attempts are recorded. If processing restarts from the beginning after interruption, remove incomplete output. If resuming is supported, verify the completed portion so that rows are neither repeated nor skipped. The implementation may vary, but its result must be explainable.
Accept the download through failure and permission changes
- Submit a job, close the page and sign in again. Retrieve the same identifier and original filters.
- Test repeated submissions, processing failures and a cancellation racing with completion. Confirm that the final state matches the real outcome.
- Change the requester's data access after completion. Reopen both the job and its download link, checking the agreed reauthorization or denial behavior.
- After expiry, verify file cleanup, disabled download access and any required retention of job records. Do not leave a permanent public file URL.
Apply the existing permission, security and audit approach to generated files, rather than checking only the export button. Use the business user acceptance testing method to record job identifiers, operation times, file checksums, row counts and monetary reconciliation. Handover should also identify queue capacity, failure alerts, cleanup rules and the person responsible for unresolved jobs.