> ## Documentation Index > Fetch the complete documentation index at: https://docs.pnbr.io/llms.txt > Use this file to discover all available pages before exploring further. # Find out whether a change happened after the reply was lost > You know whether a change happened, and you have not done it twice. Guide · core > **Use when** > > A command ended with `outcome: unknown`, exit code 4 or 5, a timeout, or no reply, and you do not know whether the change happened. > **Looking for something else?** > > A change that returned `pending` (problem [change-waits-for-approval](https://docs.pnbr.io/troubleshooting/change-waits-for-approval.md)). A submit that reports `partial` (problem [submit-partly-applied](https://docs.pnbr.io/troubleshooting/submit-partly-applied.md)). ## Outcome You can say one of three things, and you can show why. The change happened once. The change did not happen, and you sent it once with its first key. Or you cannot tell yet, and you have told the person why. ## Before you start * Stop. Do not send the change again with a new request id. * Find the request id. The CLI prints it as `request-id:` for a keyed change, and you can set it with `--request-id`. On MCP, find the call and its arguments in your own history. * Know your credential (`penumbra whoami`). A partial submit resumes only with the credential that sent it (card rule [workspace.6](https://docs.pnbr.io/concepts/workspace.md#rule-workspace-6)). ## Steps 1. Read what the exit code says. * Exit code 5 and `transport_deadline`: Penumbra did not answer in time and may still be working on it. Run the same command with the same `--request-id`. * Exit code 4 and `outcome: unknown (deadline)`: the request may have run. Its last line gives the command to run again with the same key. Go to step 2. * Exit code 4 and `outcome: pending`: that is an approval, not a lost reply (problem [change-waits-for-approval](https://docs.pnbr.io/troubleshooting/change-waits-for-approval.md)). 2. Ask Penumbra what it recorded for the key. * CLI: `penumbra requests get `. This covers Files changes: uploads, replaces, documents, collections and tags. * Expect `outcome: applied` with `replayed: true`, the operation and the File or collection it made. The change happened. Go to Check. * Expect `outcome: unknown` with `reason: request_not_observed` and exit code 4. Penumbra holds no outcome for the key. Go to step 3. 3. Read the state the change would have made. * A Files change: `penumbra files show `, `penumbra files versions ` or `penumbra files collections list`. * A workspace change: `penumbra graph workspace show ""`. Compare the item count and the revision with what you meant to do. * An extraction: `penumbra graph extractions ""`. Use the run id that `penumbra graph extract` printed. Do not build one. * MCP: call `check_status` with no reference. It lists your recent executions, up to 20 from the last 24 hours. Then call it with the reference `execution:` of the one that was running. If the state shows the change, it happened. Go to Check. If it does not, go to step 4. 4. Send the same command again, with the same arguments and the same key. * CLI: `penumbra files collections create "" --request-id ` is one example. Repeat the exact command that you ran. * Expect `outcome: applied` on the first run. If Penumbra had the outcome already, it says `outcome: applied (replayed)`. The change does not run twice with one key (problem [reply-lost](https://docs.pnbr.io/troubleshooting/reply-lost.md)). * A different body under the same key is refused with `idempotency_conflict` and exit code 3. Do not change the arguments. If you must change them, read the state again first, and use a new key only for new work. 5. A command that has no request id sends the change again if you repeat it. `penumbra graph workspace modify` is such a command. Read the workspace first (step 3), and repeat only the part that is missing. Workspace `hydrate`, `keep-new`, and `refresh` are keyed: repeat the exact command with its original `--request-id` as in step 4. 6. A submit that now reports `partial` or `unresolved` is not a lost reply. Follow problem [submit-partly-applied](https://docs.pnbr.io/troubleshooting/submit-partly-applied.md). A write that answers `graph_write_busy` did not apply: wait, then send it with the same key (problem [graph-busy](https://docs.pnbr.io/troubleshooting/graph-busy.md)). 7. If an approved change ended in `unknown`, Penumbra does not run it again. Read the state (step 3) before you ask for another approval (card rule [approval.8](https://docs.pnbr.io/concepts/approval.md#rule-approval-8)). ## Check * You have one of three proofs. `penumbra requests get ` says `applied`. Or a read of the state shows the change once. Or a repeat with the same key returned `outcome: applied`. * The count of what you changed is the same as after one change. For a collection, one collection with that name. For a workspace, the item count of one capture. ## If it goes wrong | You see | Read | | - | - | | The repeat is refused with `idempotency_conflict` | step 4: the arguments differ from the first | | The repeat returns `pending` | problem [change-waits-for-approval](https://docs.pnbr.io/troubleshooting/change-waits-for-approval.md) | | A submit reports `partial` or `unresolved` | problem [submit-partly-applied](https://docs.pnbr.io/troubleshooting/submit-partly-applied.md) | | A write answers `graph_write_busy` | problem [graph-busy](https://docs.pnbr.io/troubleshooting/graph-busy.md) | | The state shows the change twice | problem [reply-lost](https://docs.pnbr.io/troubleshooting/reply-lost.md) | | You have no request id for a change that has one | step 3: read the state, then repeat the missing part | ## Worth offering * Offer to name the request id in your report, so the person can read the same outcome later. * When a job runs many changes, offer to choose its request ids first and write them down, so a lost reply costs one lookup. * If replies get lost often, offer to report it with `penumbra feedback` (card [feedback](https://docs.pnbr.io/concepts/feedback.md)). ## Report Say whether the change happened, and how you know: the outcome that Penumbra returned for the key, or the state that you read. Say how many times you sent it, and that you used one key. If you cannot tell yet, say what you read, what is missing, and what you will check next. ## Keep going [Approval](https://docs.pnbr.io/concepts/approval.md) · [Workspace](https://docs.pnbr.io/concepts/workspace.md) · [The reply to a change was lost](https://docs.pnbr.io/troubleshooting/reply-lost.md) · [A change returned pending](https://docs.pnbr.io/troubleshooting/change-waits-for-approval.md) · [A submit is partly applied or unresolved](https://docs.pnbr.io/troubleshooting/submit-partly-applied.md) · [A Graph write returned graph\_write\_busy](https://docs.pnbr.io/troubleshooting/graph-busy.md) · [Review a workspace and submit it](https://docs.pnbr.io/guides/review-and-submit.md) Penumbra Grammar 0.6.26 This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.