What should happen when someone closes the tab mid-task?
by•
Someone starts an export, sees 70%, and closes the tab. When they come back, what should the app show? A fresh progress bar is misleading if the server kept working. 'Cancelled' is wrong unless the work actually stopped.
I'd give any job that can outlive the page an ID and store its state server-side. The simplest useful test is to start one, close the tab, then return and find the same job with its real status or result. Closing the tab and cancelling the job should be separate actions.
For a small product, when do you add this? As soon as a task can run in the background, or only after users actually lose track of work?
17 views
Replies
I'd add recovery as soon as retrying the task can charge someone twice.
In the flashcard tool I build, a generation spends a credit and saves a deck. The server can finish successfully while the browser never receives the response. If the UI treats that as a failed generation, the user may start another one and spend another credit.
I'd test that lost-response case alongside closing the tab: can the user find the saved result without paying again? A job ID helps, but the retry also needs to resolve to the same operation.
From day one, if the job costs money. In my song app a song takes a minute or more and spends credits, so each request is one document on the server from the moment it is made, and the app just listens to that document. Leave the screen, close the app, open it on another device: the song is in the library with its real status, and a push says when it is ready. The rule I carried over from an older app of mine was "poll the run, not the world": that app re-fetched every song every five minutes from a cron. Siarhei's point is the important half: the request itself must create the record, so a lost response never turns into a second paid run.