Keep long-running AI jobs working after a customer closes the tab

Start with the result the customer expects

A customer uploads a recording and asks your product to turn it into a report. They close the laptop before the report is ready. When they return, the product should show what happened and let them retrieve the result. Keeping the browser open should not be an unspoken condition of buying the service.

Before selecting a queue or workflow tool, write down the promise. What counts as a finished report? How long can the customer reasonably wait? Can they leave and come back? What happens if the input is unusable? These answers determine the work you need to preserve and the states you need to show.

Save the job before doing the expensive work

Give each accepted job a durable record linked to its owner, input and requested operation. The record needs to survive a browser refresh and a worker restart. A spinner held in page memory is useful feedback, but it is not a record of work the product has accepted.

The submission should return a job reference that the customer can revisit. Keep private inputs behind the same access controls as the result. Decide how long each is retained. An email notification can help someone return, but the application should remain the authority on whether the job actually succeeded.

There is also a gap between saving a job and handing it to a worker. Ask your engineer how accepted jobs are found if publishing to the queue fails. A transactional outbox or a reconciliation process can close that gap. Merely calling two services in sequence does not make those two steps atomic.

Show states that explain what is happening

A useful starting set is queued, processing, completed and failed. Add states only when the customer can do something with the distinction. If the system is waiting for a provider, say it is waiting; do not invent a percentage that suggests the result is nearly ready.

Separate a worker's activity from the customer's result. The provider returning successfully does not mean the report has been saved, permissions checked and made available. Mark completion only when the customer can obtain the intended output. If notification delivery fails after that point, retry the notification rather than generating the report again.

Expect a job to be delivered more than once

A queue gives work somewhere to wait. It does not remove duplicate execution. Amazon documents at-least-once delivery for standard SQS queues, so a worker must be able to receive an already handled message safely. Keep one stable job identity and check persisted state before repeating a costly or irreversible action.

A worker claim should expire if the worker disappears. In SQS, visibility timeouts help coordinate processing, and long tasks may need that timeout extended. These settings are coordination mechanisms, not a guarantee that duplicates cannot happen. Protect result publication and usage accounting with the same care as job pickup.

The difficult case is a provider completing work while your connection drops before receiving the response. If the provider supports retrieval or idempotency for that operation, use it according to its contract. Otherwise record the uncertainty and choose an explicit recovery policy. Blindly starting again can create a second charge without improving the customer experience.

Give failed work a way out

Retry a temporary failure within a defined budget. A corrupt input or rejected request will not become valid because it has been tried repeatedly. Distinguish failures that can recover from those that require a different input, a product fix or a human decision.

After the attempt budget is exhausted, keep the job inspectable. A dead-letter queue can isolate repeatedly unsuccessful messages, but somebody still needs to notice them, understand the cause and decide whether replay is safe. Assign that responsibility before customers depend on the workflow.

Customer recovery should be clear: try again with corrected input, resume from a saved step, or contact support with the job reference. Do not promise automatic cancellation of an external operation unless the provider actually supports it. Your interface and your cost accounting must agree about what stopping a job means.

Test the interruptions customers will actually cause

Use a non-production environment and representative inputs. Start a job, close the tab and reopen the product on another device. Restart a worker midway through processing. Deliver the same job message twice. Delay the provider response and interrupt the connection after it accepts work.

For each scenario, check the result, ownership, status and usage record together. The expected outcome is one understandable job with a recoverable history. A job that eventually finishes but charges twice, exposes another customer's report or remains permanently marked processing has not passed.

Also test the quiet failure: the job completes but the notification does not arrive. The customer should still find the result in their account. That distinction often exposes whether the product owns a durable workflow or merely a chain of optimistic requests.

Measure completion, waiting and recovery

Track how many accepted jobs reach a usable result, how long they wait before work starts, how long processing takes and how many need intervention. Split these measures by customer workflow or input size where that explains a difference. A low server error count cannot tell you whether anyone received their report.

Ask an engineer to show one job from acceptance through its final result, including the recovery path. If paying customers are already waiting on unfinished tasks, that is a concrete reliability problem worth addressing. You can improve that path without replacing everything else that currently works.