Before restarting a task whose window disappeared, I want to identify its existing work and read what remains. A progress bar alone cannot preserve that context.
I built a small local module that retains progress after reopening its database. It validates synthetic metadata, not a complete migration of company records.
Separate the visual indicator from the job record
A progress value held only in a page variable may disappear with the window. The lab stores company, job identifier, total and current cursor in SQLite. Another WorkLab instance can reopen the same database and read the position. Recreating a screen no longer has to imply creating another job.
The cursor alone does not prove business rows were committed. This example stores progress metadata only. A real import must define how business writes and checkpoint updates share a transaction. Persisting a number is not a guarantee of complete, correct processing of every record; it supplies an inspectable starting point for resumption.
Distinguish a new worker from the old worker
Claiming a job advances its generation and records the worker. After failure and a new claim, the earlier worker receives stale_worker instead of changing progress. Knowing the job identifier is not enough. A two-worker test also requires only one claim to succeed from the same initial generation.
That number is neither authentication nor a complete distributed lease. Company and worker are trusted synthetic context. The lab does not automatically reclaim a running worker after a timeout. Heartbeats, lease expiry and recovery policy require their own implementation. The verified boundary is that a previous generation cannot keep writing after replacement.
A repeated chunk does not advance the cursor twice
Each progress command contains an expected cursor, chunk token and count. Matching token and content replay the stored position without adding the count again. Different content under the token is rejected, as are wrong positions and progress beyond the total. Received updates and completed work ranges have distinct meanings.
A previously completed chunk can still be replayed within the same generation even after the job is done. A new chunk cannot extend the range beyond its total. Production callers need rules for token creation and retention. The contract should explain which range’s result is being read, rather than merely provide a way to increase a percentage.
Failure preserves the last confirmed checkpoint
The recorded example advances two of four items, fails and resumes from cursor two with a new worker. It stores a fixed synthetic_failure code instead of arbitrary exception text that could contain business rows or secrets. Operational diagnostics can be designed separately from the persisted job state.
The module launches no background process and performs no automatic restart. Retaining resumption metadata and waking an executor are different responsibilities. A running label without an execution signal does not settle whether work is still occurring. A connected service needs its own evidence for the state presented to the user.
State which kind of resumption was tested
Tests cover reopening, competing claims, repeated chunks, changed token content, wrong cursors and overshoot. Another test checks a new generation fencing the old worker and completion of the remaining range. The viewer displays actual local synthetic results, not a database running in the browser or a company performance benchmark.
Adoption still needs stable input ranges, real row writes, stop and cancellation authority, an executor and outcome lookup. Unlike the earlier migration article’s general discussion, this implementation tests persisted positions and generations directly. I share a small basis for reading remaining work instead of repeating a large operation from its beginning.