Workflows that survive a closed tab: durable waits with checkpoints and chrome.alarms
说明与用途
在 Chrome MV3 扩展中,长时间等待会因关闭标签页或浏览器重启而中断。解决方案是将运行状态序列化到 chrome.storage.local,并使用 chrome.alarms 通过服务工作者恢复执行。
问题
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”.
结果
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.
工作流
- 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.
证据
Browser automation dies when you close the tab is the standard objection to running workflows in an extension.
In Manifest V3 the background is a service worker, and Chrome suspends it when it's idle.
A useful checkpoint needs everything the scheduler would need to continue as if nothing happened.
If the checkpoint can't be saved, the run fails loudly at that node.
- 记录日期: 2026-11-01T11:59:06.271Z