Make one existing background job recover from interruptions without restarting its completed work. This prompt introduces Workflow around a bounded task such as preparing a report or processing an import.
Open or import your application in your coding agent and identify the job to convert. The handoff transfers only the prompt, so provide repository access separately and keep service credentials in the project’s server environment.
Expect durable steps, observable run status, and recovery tests using local substitutes for external services. Retried steps still need idempotent side effects; workflow persistence alone cannot prevent every duplicate external operation.
Convert one existing background job in this application into a resumable workflow with durable steps, bounded retries, and observable status. Read repository instructions and inspect the job entry point, framework, package manager, persistence, authorization, and existing background-work patterns. If this is not the intended repository, ask me to open or import it. Ask which job to convert only if the scope is unclear. Read current Workflow documentation and any installed SDK version’s APIs and runtime constraints. Preserve the app’s framework and reuse existing storage and UI; explain an incompatible dependency before proposing a migration. Map the job’s inputs, outputs, and external effects. Keep workflow orchestration deterministic and place network calls and other supported effects in steps. Pass only serializable data, avoid storing secrets in run inputs or outputs, and validate and authorize job requests on the server. Use opaque run identifiers and restrict status or result access to the initiating user or tenant. Return an accepted run identifier promptly and expose pending, running, completed, and failed status through existing application patterns. Preserve completed work during recovery. Distinguish temporary failures from permanent validation or authorization failures, with bounded retries and delays appropriate to the service. Give exhausted failures an actionable status and a documented recovery path. Prevent duplicate starts for the same logical operation as well as duplicate effects inside a retried step. Use existing atomic storage controls and stable idempotency keys accepted by downstream services. A crash can occur after an external write succeeds but before the step records its result. If the destination cannot deduplicate or reconcile that outcome, stop for operator review instead of claiming exactly-once execution or automatically repeating the write. Use local fixtures and fake services to verify success, a temporary error that recovers, a permanent error, retry exhaustion, interruption after an external effect, duplicate starts, and another user requesting run status. Use the SDK’s supported local runtime or testing tools where available; distinguish simulated retries from a real runtime interruption test. Implement locally. Ask before provisioning paid services, running real jobs, deploying, or changing production data. Finish with changed behavior, actual commands and results, blocked runtime checks, configuration and local run steps, and recovery limitations.