Your agent task submission times out. You send it again, and the same change becomes two assignments. The safer first move is to identify the original request and inspect what happened to it.
OpenRig 0.6.5, released October 4, 2026, adds a useful recovery detail: rig queue create chooses an item ID before sending the request and prints it to stderr. After a timeout, that ID lets you look for the original item and, when appropriate, retry with the same identity. This is a documentation-based recovery checklist, not a hands-on reliability test.
Keep delivery, ownership and completion separate
OpenRig coordinates persistent teams of coding agents. Its messaging guide distinguishes a message from a tracked assignment: rig send does not create a queue row, and its --verify option confirms text appeared in the pane, not that an agent read or acted on it.
Think of three separate questions: did the request reach the system, who owns the resulting work, and did the requested outcome pass review? An answer to the first question cannot settle the other two.
This checklist is for an already authorized queue-create request with an uncertain outcome. It is not a retry recipe for deployments, payments, queue handoffs or task closure. Do not broaden permissions or start another daemon merely because a request failed.
Before retrying, collect the request's identity
Save the original command's output, including stderr, and the exact request you intended to submit. In 0.6.5, the request-ID line goes to stderr even with --json; stdout remains the JSON result. If your logging captures only stdout, your recovery evidence may be incomplete.
Use the following small record. It is an original operator checklist, not an OpenRig configuration format. Keep secrets and private task contents out of shared incident notes.
| Field | What to preserve | Why it matters |
|---|---|---|
| Instance | The intended daemon endpoint and relevant OpenRig home selection | An empty answer from another instance says nothing about this submission |
| Task ID | The exact ID emitted for this attempt | A newly generated ID describes a different creation request |
| Routing | Original source, destination and any explicit remote routing | A retry must not silently send the same work elsewhere |
| Payload | Unchanged body and other creation options; preserve the input file if used | A file edited since submission may no longer reproduce the original request |
| Observation | Timestamp, exit status and exact error or warning | “Timed out” is different from an explicit rejection |
The version-pinned queue implementation supports an explicit --id on create. The daemon’s same-ID handling preserves an existing row rather than overwriting it. Preserve the whole original request, rather than treating the ID as a way to amend the body.
Read the exact item on the intended daemon
The coordination reference documents rig queue show <id> --full --json for the complete item and rig queue transitions <id> for its separate history. Replace the placeholder with the saved ID. Read both when the item exists, and check the actual destination, body and current state.
For a forwarded request, take extra care with the read target. The pinned queue implementation explains that queue reads do not follow the sticky host selection. The missing-item diagnostic change names the daemon queried; it does not change routing. Verify the intended destination URL using rig host list, then use OPENRIG_URL='<verified-destination-daemon-url>' rig queue show '<original-id>' --full --json. Replace both placeholders with verified values and use the same endpoint for the transitions read. A missing-item message from the wrong daemon is not evidence that creation failed.
For example, imagine an authorized local task to improve a fictional recipe application's empty-search message. The create call times out after printing an ID. A fresh create with another ID could record the same assignment twice. First locate the original ID and compare its body with the preserved brief. Do not use this example's labels as real task identifiers.
Choose the next step from evidence
| What you observed | What it establishes | Next step |
|---|---|---|
| Original item exists with the intended request | The task was recorded | Continue following that item and its owner; do not create a second assignment |
| Item exists but its contents differ | Your saved intent and recorded work disagree | Stop the retry and resolve the mismatch through the normal authorized correction process |
| Successful lookup says the ID is missing on the verified destination | The item was absent at that read | If the original action remains authorized, use the same ID and unchanged request for any retry; an in-flight write may still complete |
| Lookup fails, or the instance cannot be established | The outcome remains unknown | Resolve the read or routing problem; do not relabel it “absent” |
| The original ID is unavailable | You cannot yet link a retry to the first submission | Recover logs and inspect existing work with its owner before creating anything else |
The subtle case is the third row. A read can finish before a delayed write. The queue-create recovery change therefore emphasizes the same ID, same request and same endpoint. It does not turn a timeout into proof of failure or promise that every downstream action happens exactly once.
A retry should preserve the original arguments and add the saved --id if it was originally generated for you. Do not substitute a new body, source, destination or options. If you no longer want the original work, resolve that changed intent first. A user cancellation or permission denial is a stop condition, not a transient network error.
Read warnings even when a retry returns success
According to the 0.6.5 release notes, a same-ID retry with a different body warns that the new body was not saved. A successful command result can therefore accompany an unchanged older assignment. Read the row again and compare it; do not infer that your revised wording took effect. The implementation notes say this warning requires the updated daemon and compares the body only. An older daemon may return the original row silently; no warning does not prove that changed options were saved.
For the fictional search-message task, suppose the first brief asked for wording only, but the retry input file now also asks for a layout change. Those are different requests. Recover the recorded task, discuss the expanded scope with its owner, and use the normal amendment process. Repeating create is not a reliable editing workflow.
Also resist treating a task's closed state as the result you wanted. The coordination reference distinguishes closure from acceptance: a handoff can close the sender's row while the receiving stage still owes its verdict. Follow the linked next step and inspect the actual artifact before saying the feature is complete.
Leave a short recovery record
After reconciliation, record the verified instance, original task ID, observation time, current owner and next action. Link the task history and the resulting artifact when available. An honest note might say: “Original row found; no second assignment created; owner still working; review pending.” That statement closes the duplicate-submission question while leaving unfinished work visible.
Before using OpenRig for the first time, read its machine-change disclosure. Setup and operation can write hooks, trust records and provider configuration; a dry-run of setup does not preview every later startup effect. This guide does not require installing or upgrading anything, changing network settings, or granting broader access.
The useful habit is small: preserve the identity, inspect the destination, and continue the original obligation. If that obligation must move to a later session, the coding handoff checklist helps preserve its evidence without turning uncertainty into a new task.