A missing response does not prove a missing effect
Imagine an agent runs a command that publishes a package. The process completes, but the device loses its network connection before reporting the result. From the agent's view, the request has not succeeded. Repeating the command may publish twice or fail for a reason that hides the first successful effect.
A short wait ending is an easier case: keep the returned jobId and follow the existing task. A device crash during execution is harder because the affected resource may have changed without a terminal result. ADC distinguishes these situations instead of treating every missing response as permission to retry.
adc task wait JOB_ID --wait 4000 --jsonPreserve the identity and the request
Mutating requests carry an idempotency key. Keep it with the invocation ID, returned jobId, target and arguments. Matching retries can refer to the original operation; changing the request while keeping the key is a conflict. A new key represents a new operation and bypasses the protection associated with the old one.
The device compares the key and normalized request identity, not a natural-language description of intent. If the agent rewrites a command or changes an execution budget, do not assume it remains the same request. Keep the original request for recovery, then make a separate, deliberate decision about any corrective action.
The device records before and after execution
Before starting a side effect, the Connector durably reserves its identity in a local ledger. The started record is persisted with fsync and an atomic file operation. After the executor returns, the Connector persists the completed receipt before reporting it to the service. A lost completion response can therefore be reconciled from local evidence.
A matching completed record can replay the recorded result without executing the side effect again. A started record without a reliable completion record is different: it proves the operation was reserved, but cannot prove how far it got. This is why the ledger stores both phases rather than just caching successful responses.
The receipt describes what the executor observed. It is not a transaction with every filesystem, database or external API touched by the command, and it cannot undo those effects. Programs with their own transaction or idempotency support provide stronger resource-level recovery.
Handle unknown_outcome explicitly
If there is no trustworthy terminal receipt and execution cannot be ruled out, the safe answer is unknown_outcome. Stop automatic retries. Inspect the existing task and the target resource: does the published version exist, was the expected file written, or does the external service have a matching transaction?
Only after reconciliation should the operator or agent choose the next action. If the effect exists, continue from it. If absence can be established, a new operation may be appropriate. If the evidence stays uncertain, preserve that uncertainty instead of inventing an exactly-once guarantee or retrying under a fresh key.