Find out whether a change happened after the reply was lost

​

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).

​

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).
2. Ask Penumbra what it recorded for the key.
   • CLI: penumbra requests get <key>. 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 <file>, penumbra files versions <file> or penumbra files collections list.
   • A workspace change: penumbra graph workspace show "<name>". Compare the item count and the revision with what you meant to do.
   • An extraction: penumbra graph extractions "<workspace>". 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:<id> 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 "<name>" --request-id <key> 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).
   • 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. A write that answers graph_write_busy did not apply: wait, then send it with the same key (problem graph-busy).
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).

​

Check

• You have one of three proofs. penumbra requests get <key> 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

​

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).

​

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 · Workspace · The reply to a change was lost · A change returned pending · A submit is partly applied or unresolved · A Graph write returned graph_write_busy · Review a workspace and submit it