Skip to main content
Troubleshooting · graph

Use when

A submit was refused with workspace_review_conflict, or validate reports witness_stale, or a workspace write reports workspace_revision_conflict.

Looking for something else?

A submit that is partly applied (problem A submit is partly applied or unresolved). A direct entity update that was refused (card Entity, rule entity.1).

​
Signs

  • penumbra graph workspace submit "<name>" --revision <n> exits with code 3 and prints workspace_review_conflict: The reviewed workspace revision or submission has changed. Read it again before applying or resuming.
  • Validate or submit prints the diagnostic witness_stale with text such as moved from revision A to B since it was hydrated; refresh it to continue.
  • A write to the workspace returns workspace_revision_conflict, with the text another call changed this workspace at the same time.
  • Nothing was applied.

​
Why it happens

A change to a workspace raises its revision. You reviewed revision n. Before you submitted, someone else or another call of yours changed the workspace, so the revision is no longer n. The reviewed revision is a guard (card Workspace, rule workspace.4). A witness_stale diagnostic has a second cause. The existing entity that you checked out changed after you checked it out (rule workspace.8). If the workspace has status submitted, you may have used the wrong revision to resume. Then follow problem submit-partly-applied.

​
What Penumbra does

By itself:
  • Refuses the submit before it compiles the workspace or has any effect.
  • Leaves the workspace and its staged items as they were.
  • Blocks a submit when an edit wins the final check at the same moment.
You must:
  • Read the workspace again.
  • Decide if the new content is still what the person reviewed.
  • Validate, then submit the new revision.
Not handled:
  • Nothing merges two sets of edits.
  • Known issue: a submit that must wait for approval can return pending even when the revision you sent is already out of date. Read the workspace again after the approval is decided, before you trust the result.

​
Do

  1. Read the workspace: penumbra graph workspace show "<name>". Note its revision and its items.
  2. Compare the items with what the person reviewed. If an item changed, show the person the difference before you go on.
  3. If the diagnostic is witness_stale, refresh the out-of-date item with penumbra graph workspace refresh "<name>" <handle>. Your change stays on the fields that did not change. A field that changed loses your change and is named in a flag (rule workspace.13). Set that field again with penumbra graph workspace modify.
  4. Validate: penumbra graph workspace validate "<name>". Use the revision in its next: line. If that line names penumbra graph workspace show instead of a submit, review flags remain: read the workspace, then submit its revision.
  5. Submit that revision: penumbra graph workspace submit "<name>" --revision <new>.

​
Don’t

  • Don’t send the same submit again with the new revision before you read the workspace. That applies changes that nobody reviewed.
  • Don’t leave out --revision to get past the error. Without it, nothing checks which revision applies.
  • Don’t check the same entity out again to refresh it. The CLI says that it is already hydrated, and the old copy stays. Use penumbra graph workspace refresh.
  • Don’t use the current workspace revision to resume a submit that is already submitted.

​
Check

  • penumbra graph workspace validate "<name>" prints valid: yes at the revision that you pass to the submit.
  • The submit returns applied, or waits for approval (problem change-waits-for-approval).
Card rules workspace.4, workspace.8 and workspace.13. Recipe review-and-submit. Problem submit-partly-applied.

​
Keep going

Workspace · Entity · Review a workspace and submit it · A submit is partly applied or unresolved