Internal error: Unexpected error from backend

[Maverik]

I have not been able to exactly pin down how I'm managing to do this, but it is practically a daily problem, and I shall endeavour to provide as many details as I can from my observation.

Apologies in advance for not following the exact template.

Each time I start a new Window's session (Power cycle / log off & on), my JJ metadata seems to be getting corrupted due to something holding JJ back, and I get the following:

Error Log

❯ jj git fetch --debug
2024-12-17T23:16:42.076924Z INFO jj_cli::cli_util: debug logging enabled
2024-12-17T23:16:42.110440Z DEBUG globset: glob converted to regex: Glob { glob: "/[Bb]in", re: "(?-u)^(?:/?|.*/)[Bb]in$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true, empty_alternates: false }, tokens: Tokens([RecursivePrefix, Class { negated: false, ranges: [('B', 'B'), ('b', 'b')] }, Literal('i'), Literal('n')]) }
2024-12-17T23:16:42.110750Z DEBUG globset: glob converted to regex: Glob { glob: "/[Oo]bj", re: "(?-u)^(?:/?|.*/)[Oo]bj$", opts: GlobOptions { case_insensitive: false, literal_separator: true, backslash_escape: true, empty_alternates: false }, tokens: Tokens([RecursivePrefix, Class { negated: false, ranges: [('O', 'O'), ('o', 'o')] }, Literal('b'), Literal('j')]) }
2024-12-17T23:16:42.110946Z DEBUG globset: built glob set; 0 literals, 5 basenames, 0 extensions, 0 prefixes, 0 suffixes, 0 required extensions, 2 regexes
Internal error: Unexpected error from backend
Caused by:
1: Failed to read non-git metadata
2: Failed to lock table store
3: Timed out while trying to create lock file: \?\C:\git\AoC2004.jj\repo\store\extra\lock
4: The file exists. (os error 80)

---

Note that, The file exists., isn't the real issue. It did not exist at the time command was run & isn't limited to fetch or commit (the two I tend to use). Once I reach this state, I can only wipe .jj folder and reinstate it with --colocate and everything will work as expected until the next reboot.

My best guess is gpg signing is the problem. Upon fresh login, my gpg-agent isn't up, and it takes time on first sign request to boot up. Occasionally, it can take long enough to cause a timeout in git and I would simply issue git commit again and next time it'll pop up with the Pinentry program expecting the password to unlock the key.

With JJ, I never get that option once it goes in timeout. Instead, JJ is permanently stuck with the above error until I delete the .jj folder.

I have tried this on two different machines, both with very different setups (one is my work machine heavily restricted by policies and the other is a home machine with full administrative access and no antivirus or anything else of intrusive nature active).

Also, based on another issue I tried running with --ignore-working-copy and to my surprise, that works fine.

❯ jj git fetch --ignore-working-copy
Nothing changed.

However, I'm not sure if that is an option when I'm trying to jj commit -i. There is no other program active that is trying to commit or even read git status.

Specifications

• Platform: Windows
• Version: 0.24.0-70e796a6b622dfdf135c353e6765b2066bb6cc62 (Rust Nightly / MSVC 2022 toolchain)
  (running on SSH PR branch, but the experience has been same on mainline)

[martinvonz]

Note that, The file exists., isn't the real issue. It did not exist at the time command was run

Do you mean that it didn't exist before you ran the command? Or that it didn't exist after the command was run? Or both?

My best guess is gpg signing is the problem. Upon fresh login, my gpg-agent isn't up, and it takes time on first sign request to boot up.

Do you have Watchman-triggered snapshots enabled (https://jj-vcs.github.io/jj/latest/config/#watchman)? I can imagine things going wrong if those snapshots need to ask for an action from you.

[Maverik]

Do you mean that it didn't exist before you ran the command? Or that it didn't exist after the command was run? Or both?

It did not exist before executing the command, but it was left in there after the timeout and I cleaned it up (and retried for the same result).

Do you have Watchman-triggered snapshots enabled (https://jj-vcs.github.io/jj/latest/config/#watchman)? I can imagine things going wrong if those snapshots need to ask for an action from you.

I have not done this. I'm in fairly vanilla configuration (this is the entire file):

[snapshot]
max-new-file-size = "100KiB"

[signing]
sign-all = true
backend = "gpg"
key = "[Hex Key]!"

[user]
name = "Maverik"
email = "Maverik@[Redacted Domain]"

[ui]
editor = "code-insiders.cmd -w"
diff-editor = ":builtin"
default-command = ["log"]
pager = "delta"

[ui.diff]
format = "git"

[martinvonz]

On Linux and Mac, we use flock for locking. On Windows, we use https://github.com/jj-vcs/jj/blob/main/lib/src/lock/fallback.rs instead. Perhaps there's a bug there somewhere, or perhaps it's just that we don't get a chance to clean up the lock file if our process doesn't exit gracefully.

[Maverik]

While the clean-up would be nice to have, in this instance, that's just a symptom of the problem. I can clean it by hand, but it will just repeat itself until I nuke .jj folder. Right now, I've already done my jj folder reset, and I'm running OK even across reboots.

I've tried it with both signing off & on but with no working copy changes and so far it's working. I'll have to report back next time it does the thing again. Might be the fact I'm doing changes (0-200 line change while I'm doing AoC 2024 content) and that's triggering something that then combines with GPG timeout to somehow corrupt the metadata.

If there's something I can capture for further debug information, please let me know, and I'll post more details next time I run into it.

[Maverik]

I just wanted to leave an update here to say this issue isn't abandoned. However, for whatever random reason, I've yet to break it on my home machine again since last reset. My work machine had JJ in broken state, but I won't back on it until start of next year. I'll reset that install and see if either one of the machines break again and if I can get more details out to help debugging the issue.