op show complains "commit not found in index" – repo corruption?

[keysmashes]

My repo has got into an odd state. I don't know if I can safely jj abandon things until it looks ok again, or if there is actually some corruption and/or risk of data loss (and/or if there is a bug that needs fixing).

The first few lines of jj log show a conflicted change ID vt:

@  vttuonqm?? me 2025-06-03 13:10:27 5c36c8f7
│  (no description set)
│ ·  vttuonqm?? me 2025-06-03 13:01:57 789da0e8
├─╯  (empty) (no description set)
·  zuwzuzov me 2025-06-03 13:01:57 git_head() d14c405e
│  Upgrade @eslint-react/eslint-plugin to avoid bug in useState detection
·  vnssmxrm me 2025-06-03 12:49:55 3745fb4b
│  Abstract away direct use of setState in useEffect

Ok, so we have 5c which is the actual changes I was working on, and 78 which is empty and useless(?). I think I could just jj abandon 78, but I'm curious how that happened; let's look at jj op log (the jj log --color always invocations are from my prompt, trimmed for brevity):

@  d0f50d7e353c me@myhost 5 minutes ago, lasted 79 milliseconds
│  snapshot working copy
│  args: jj log --color always ...
○  481decce9ca9 me@myhost 9 minutes ago, lasted 19 milliseconds
│  snapshot working copy
│  args: jj log --color always ...
○  b56e9ad3972b me@myhost 9 minutes ago, lasted 81 milliseconds
│  snapshot working copy
│  args: jj show
○    88cf620ea7a0 me@myhost 14 minutes ago, lasted 80 milliseconds
├─╮  reconcile divergent operations
│ │  args: jj log --color always ...
○ │  e42677f57228 me@myhost 26 minutes ago, lasted 71 milliseconds
│ │  snapshot working copy
│ │  args: jj log --color always ...
│ ○  f70a6e922269 me@myhost 14 minutes ago, lasted 12 minutes
├─╯  describe commit e39e9f7e40e1503fb6d53e60892b22404dd6cf60
│    args: jj desc vn
○  403708f27ca4 me@myhost 27 minutes ago, lasted 21 milliseconds
│  squash commits into d31ca254b5a1067f9fa0adcd4d1367396d3f6540
│  args: jj squash

Ok... at this point I think the sequence of events was something like this:

• I jj describe vn, open another tab, and forget about the editor I've left open (f70a6e922269)
• I go and make some more changes (e42677f57228)
• I come back to the description editor, write a description, and save and quit (also f70a6e922269)
• jj tries to figure out what the result of that should be (88cf620ea7a0)
• then it takes me a few more minutes to notice that something strange has happened

So I think op 88cf620ea7a0 did something strange, potentially. Let's jj op show -p 88cf620ea7a0:

88cf620ea7a0 me@myhost 25 minutes ago, lasted 80 milliseconds
reconcile divergent operations
args: jj log --color always ...
Error: Commit ID 0b8bb3c8d572b6331e5b2db9ab33ee023fe55308 not found in index (index or view might be corrupted)

...what.

The change ID (introduced in 403708f27ca4) is already conflicted by the op after 88cf620ea7a0:

b56e9ad3972b ah37@mib117989s 26 minutes ago, lasted 81 milliseconds
snapshot working copy
args: jj show

Changed commits:
○  + vttuonqm?? c3273901 (no description set)
   - vttuonqm hidden c8ae9282 (no description set)

Changed working copy default@:
+ vttuonqm?? c3273901 (no description set)
- vttuonqm hidden c8ae9282 (no description set)

and looking at the two parallel ops, they clearly did both make modifications to vt:

e42677f57228 me@myhost 46 minutes ago, lasted 71 milliseconds
snapshot working copy
args: jj log --color always ...

Changed commits:
○  + vttuonqm b311eacf (no description set)
   - vttuonqm hidden 51c50298 (empty) (no description set)

Changed working copy default@:
+ vttuonqm b311eacf (no description set)
- vttuonqm hidden 51c50298 (empty) (no description set)

f70a6e922269 me@myhost 34 minutes ago, lasted 12 minutes
describe commit e39e9f7e40e1503fb6d53e60892b22404dd6cf60
args: jj desc vn

Changed commits:
○  + vttuonqm 789da0e8 (empty) (no description set)
│  - vttuonqm hidden 51c50298 (empty) (no description set)
○  + zuwzuzov d14c405e Upgrade @eslint-react/eslint-plugin to avoid bug in useState detection
│  - zuwzuzov hidden 3960fa94 Upgrade @eslint-react/eslint-plugin to avoid bug in useState detection
○  + vnssmxrm 3745fb4b Abstract away direct use of setState in useEffect
   - vnssmxrm hidden e39e9f7e (no description set)

Changed working copy default@:
+ vttuonqm 789da0e8 (empty) (no description set)
- vttuonqm hidden 51c50298 (empty) (no description set)

so it makes some sense that vt is now conflicted (even though I wish jj was smart enough to automatically resolve "one side changes the content, the other side changes the description"), but it doesn't seem right that jj op log -d now just breaks when it gets to 88cf620ea7a0.

(it seems like this is ~identical to #4465?)

[yuja]

Error: Commit ID 0b8bb3c8d572b6331e5b2db9ab33ee023fe55308 not found in index (index or view might be corrupted)

iirc, jj op show/diff had problems on handling of merge operations. If jj log --at-op <op-id> worked, the index wouldn't be corrupted.

[keysmashes]

jj log --at-op 88cf620ea7a0 does indeed work, that's reassuring.