Summary
Paused (approval-gated) executions are stored in memory, so a resume after a server/process restart fails permanently. On a hosted/self-host deployment where dynos cycle (Heroku recycles ~daily, and any redeploy/restart), an approval that was requested before a restart can never be completed.
Environment
- App:
@executor-js/host-selfhost (self-host), deployed on Heroku (Bun buildpack), Heroku Postgres as the durable store (DATABASE_URL).
- MCP over streamable HTTP, headless API-key auth.
- Durable DB state (integrations, connections, secrets, invite codes, Better Auth sessions) all persist correctly across restart — only paused-execution/approval state does not.
Reproduction
- Trigger an approval-gated execution via the
execute meta-tool (e.g. openapi.addSpec, which pauses with status: waiting_for_interaction). Capture the executionId (e.g. exec_74f3a0ef-...).
- Restart the server process (
heroku ps:restart, or any redeploy/dyno cycle).
- Re-initialize the MCP session and call
resume with the original executionId and action: "accept".
Expected
The approval can be resumed after a restart when the underlying app state (DB) is durable, or at minimum the limitation is documented.
Actual
resume returns an error result:
Paused execution is unknown: exec_74f3a0ef-... Paused executions are only resumable for a limited window; this id may have expired or never existed. To recover, run the execute tool again with the original code; if it pauses, a fresh executionId will be issued.
The paused-execution registry is process-memory only, so the id is gone after restart. (The error is handled gracefully — no crash — but the approval cannot be completed.)
Impact
On any multi-restart deployment, approval-gated writes requested before a restart are unrecoverable; users must re-issue the original call to get a fresh executionId. Worth either persisting paused-execution state alongside the other durable stores, or documenting that approvals must be re-requested after a restart.
Summary
Paused (approval-gated) executions are stored in memory, so a
resumeafter a server/process restart fails permanently. On a hosted/self-host deployment where dynos cycle (Heroku recycles ~daily, and any redeploy/restart), an approval that was requested before a restart can never be completed.Environment
@executor-js/host-selfhost(self-host), deployed on Heroku (Bun buildpack), Heroku Postgres as the durable store (DATABASE_URL).Reproduction
executemeta-tool (e.g.openapi.addSpec, which pauses withstatus: waiting_for_interaction). Capture theexecutionId(e.g.exec_74f3a0ef-...).heroku ps:restart, or any redeploy/dyno cycle).resumewith the originalexecutionIdandaction: "accept".Expected
The approval can be resumed after a restart when the underlying app state (DB) is durable, or at minimum the limitation is documented.
Actual
resumereturns an error result:The paused-execution registry is process-memory only, so the id is gone after restart. (The error is handled gracefully — no crash — but the approval cannot be completed.)
Impact
On any multi-restart deployment, approval-gated writes requested before a restart are unrecoverable; users must re-issue the original call to get a fresh
executionId. Worth either persisting paused-execution state alongside the other durable stores, or documenting that approvals must be re-requested after a restart.