Recover after a failed task
After a task stops, errors, or fails to reply, establish what it already did before retrying. Repairing a connection or restarting a service does not undo file changes, messages, publications, or charges.
Check whether effects are continuing
If work is still repeatedly writing, sending, or incurring costs, stop further execution through the relevant task or service entry. For exposed credentials or untrusted tools, use Security incident handling.
For a single failure with no continuing effects, retain the error, task identifier, time, and outputs. Do not delete chats, logs, or project files to obtain a clean state; they help establish what happened.
Recover according to the actual action
| Situation | Establish first | Recovery |
|---|---|---|
| Read or generation failed without writing | Error, input, connection status | Fix the cause and retry a small task |
| Local files changed | Diff, pre-existing uncommitted work, backups | Restore only changes you intend to undo |
| Message or content submitted | Actual destination result | Keep a confirmed success; do not resend |
| External result remains unknown | Request time, identifier, account, destination | Query the result before retrying |
| A charge occurred | Provider transaction and bill | Follow provider rules; local failure does not imply no charge |
Preserve your own work when restoring files. Do not overwrite an entire directory to undo one task. With version control, inspect the diff and identify the failed task's changes before restoring them.
Example: no reply after sending a message
Open the destination service and check recipient, content, and time. Do not resend a confirmed success. If it was not sent, repair the connection before submission. If the outcome is still unknown, retain the request identifier and continue checking. A reply timeout does not establish that the destination did nothing.
Apply the same sequence to publication, record creation, and other writes. Restarting the app restores the entry point; it does not change an existing external result.
Return to normal use
- Save existing results and distinguish success, failure, and unconfirmed actions.
- Use Find problems and collect diagnostics to locate the cause and repair the relevant connection or setting.
- For background-service failures, follow Desktop service maintenance and wait for readiness.
- Run a small, low-impact check before continuing the original task. Use a verified backup when restoring files.
- Inspect the local or external destination and check for duplicate actions.
Do not use standalone Evolver lifecycle commands to stop Desktop tasks. Self-hosted runtimes use Runtime policy and budgets and Pilot rollout and acceptance in Developers.
If recovery still fails
Retain version, error, reproduction steps, attempted fixes, and unconfirmed outcomes. Prepare redacted support details using the diagnostics guide. Service recovery and original-task completion are separate: continue reconciling unknown writes or charges even after the error disappears.