Concurrent jj workspace add can leave the calling workspace unusable with sibling-operation internal error #9314

Description

Running multiple jj workspace add commands concurrently from the same workspace can leave the original workspace unusable immediately afterward.

In my case, jj reported:

Concurrent modification detected, resolving automatically.
Internal error: The repo was loaded at operation cc596ad0b53a, which seems to be a sibling of the working copy's operation 8ff81247ea4c
Hint: Run `jj op integrate 8ff81247ea4c` to add the working copy's operation to the operation log.

This seems worth tracking separately from the more general “sibling of the working copy's operation” reports because the trigger is a very small, concrete repro using workspace add itself.

Recovery message is insufficient

Attempting to run jj op integrate as hinted doesn't actually work, presumably because of the broken state.

Instead, that recovery command has to be run with --ignore-working-copy, which I think a casual user would be unlikely to figure out.

Repro

I initially ran into this with an agent trying to create and work in 8 workspaces concurrently. Further investigation revealed that it's definitely sensitive to the number of workspaces involved.

On my Mac, I've been able to reproduce this with a slightly smaller number of workspaces, but it either doesn't happen or is much less common with 5 or fewer workspaces.

tmp=$(mktemp -d /tmp/jj-concurrency-repro.XXXXXX)
jj git init "$tmp/repo"
cd "$tmp/repo"

COUNT=6

seq 1 $COUNT | xargs -P$COUNT -I{} sh -c \
  'jj workspace add ../ws-{} --name ws-{} >"$tmp/ws-{}.log" 2>&1'

jj status

Actual behavior

The workspace add commands create the workspaces, but the original workspace can then fail immediately on a normal command like jj status with:

Concurrent modification detected, resolving automatically.
Internal error: The repo was loaded at operation cc596ad0b53a, which seems to be a sibling of the working copy's operation 8ff81247ea4c
Hint: Run `jj op integrate 8ff81247ea4c` to add the working copy's operation to the operation log.

Also, some of the per-workspace logs contain:

Concurrent modification detected, resolving automatically.

For example, in my repro two of the workspace add logs reported that message.

jj --ignore-working-copy workspace list still shows that all workspaces were created successfully.

Expected behavior

Concurrent jj workspace add should not leave the calling workspace broken.

At minimum, if jj says it is “resolving automatically”, I would expect the original workspace to remain usable without requiring a manual jj op integrate ... or jj workspace update-stale.

Version

jj 0.40.0-941d0290f5511db1d1cf8e4fe7365ba7d1828ea0

Additional context

I found issue #8737, which looks related by symptom, but this repro is much narrower (and presumably much easier to trigger in this agent-happy world):

• fresh repo
• no other commands needed
• just concurrent workspace add
• immediate failure in the original workspace