Workflows that survive a closed tab: durable waits with checkpoints and chrome.alarms

Description and use

In Chrome MV3 extensions, long waits are interrupted by tab closure or browser restart. The solution serializes run state to chrome.storage.local and uses chrome.alarms to resume execution via a service worker.

Problem

Browser automation workflows in extensions stop when the tab or background service worker is closed or the browser restarts, preventing long waits such as “wait 3 days, then check again”.

Outcome

Implemented durable waits that survive tab closure and browser restarts by serializing full run state to chrome.storage.local and using chrome.alarms to wake the service worker after the specified delay.

Workflow

• 1. Node signals a suspend request with a resumeKey and kind (timer or approval).
• 2. Engine throws a SuspendSignal, unwinds the queue, and writes a checkpoint to chrome.storage.local. The checkpoint includes resumeKey, workflowId, pausedNodeId, kind, meta, pausedInput, queue, visited, wasVisited, nodeOutputs, runVariables, nodeExecutionCtx, parentLink, and createdAt.
• 3. For timer suspends, the checkpoint triggers chrome.alarms.create with the resumeAt timestamp. The app page messages the service worker to set the alarm.
• 4. When the alarm fires, the service worker’s onAlarm listener restores the checkpoint, rebuilds queue, visited sets, outputs, and variables, and resumes execution from the paused node.
• 5. If checkpoint serialization fails, the run fails loudly at that node to avoid silent loss of state.

Evidence

Browser automation dies when you close the tab is the standard objection to running workflows in an extension.

Source

In Manifest V3 the background is a service worker, and Chrome suspends it when it's idle.

Source

A useful checkpoint needs everything the scheduler would need to continue as if nothing happened.

Source

If the checkpoint can't be saved, the run fails loudly at that node.

Source