pure: git info eventually stops being updated

I just ran into this on again (master branch), and it seems I was able to be able to bring back to life by doing:

prompt_pure_async_init=0; async_stop_worker prompt_pure

Can anybody else confirm this? It doesn’t really provide clues to the underlying issue, but could help us work around it in the meantime.

@mattpolito has funded $40.00 to this issue.

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

@sindresorhus do you plan to release a new version with this fix?

@mafredri been trying indestructible-pure branch the last few days and I have yet to run into git info issues or 100% CPU usage

@sindresorhus thanks for confirming.

I’ve found what I believe to be the ~reason for this. Well, I can’t explain why it happens, but at least where.

There’s now a new PR open in zsh-async (https://github.com/mafredri/zsh-async/pull/37) which addresses it and a few more improvements fueled by paranoia. I believe this is where we ran into trouble until now: mafredri/zsh-async#37/files#diff-c7f89cff42efffc19f69071441a12a1cR170-R174.

I’ve now created the indestructible-pure branch, which listens to the new signals from zsh-async and should allow for recovery on next prompt. I managed to trigger the issue a few times before making all of the above changes, but after I added the handling in Pure, I could no longer 😅.

Anyway, please try it out. Ideally, as a next step, I’d like to automatically detect worker crashes in zsh-async and do the restart there, but we’ll see.

@sindresorhus has rewarded $72.00 to @mafredri. See it on IssueHunt

• 💰 Total deposit: $80.00
• 🎉 Repository reward(0%): $0.00
• 🔧 Service fee(10%): $8.00

Had some time last weekend to work on this and wrapped it up today, the final iteration of zsh-async and pure worker restarting is now in #543. Please, for anyone affected, give it a spin and report any issues here.

Workers can still crash, but restarts are completely transparent and should not result in any inconveniences for the user.

Can anybody else confirm this? It doesn’t really provide clues to the underlying issue, but could help us work around it in the meantime.

I just reproduced the issue on my local system and running the command prompt_pure_async_init=0; async_stop_worker prompt_pure fixed it for me.

The git dirty status * just got stuck when using testfix1. It stays there even when the branch is not dirty. Restarting the terminal app makes the * disappear.

I switched to fast-syntax-highlighting but the issue persists.

In case anyone runs into this problem: In switching to the indestructible-pure branch, I ran npm -g uninstall pure-prompt because I wanted to be sure I was using the git-cloned branch. After I did this, I started getting the following error message when I started a new terminal

Couldn't read file /usr/local/share/zsh/site-functions/prompt_pure_setup containing theme pure.

Turns out npm uninstall left a broken symlink with this name. Removing the broken symlink got rid of the error.

I believe I ran into this myself now, while running a build task many consecutive times on an old JS project that used gulp.

I tried removing the pure async worker and recreating it, but that didn’t help which suggests Zsh is stuck somehow.

I noticed an interesting thing though, when I tab-complete (two times), a flood of async messages come through (all that were stuck), but it after that they’re stuck again

If you want to try this, you can add this to your .zshrc and run setcb when the issue arises:

prompt_pure_async_callback2() {
  local -a args=("$@")
  typeset -p args; print
  prompt_pure_async_callback "$@"
}

setcb() {
  ASYNC_CALLBACKS[prompt_pure]=prompt_pure_async_callback2
}

Ultimately we need to figure out what triggered it and what’s keeping it stuck, though. Issue could be in Zsh internals / zpty.

For now, if you run into the issue, you can run exec zsh in your tab to replace the current shell with a new, working one.

I’d also be interested to know if anyone of you can reproduce the issue with 6203b39715580950e17767dd8b27954af2d08c31? It’s just a hunch at this point but wondering if #430 might have made this issue appear.

Hmm, I use / or have used all three myself (albeit my own fork of z with flock:ing and I’ve recently moved to zsh fast-syntax-highlighting) so not sure if there’s any clue in those.

Could you try changing this line:

https://github.com/mafredri/zsh-async/blob/98d32afcce8e328be86f381c529e951943e57d19/async.zsh#L71

to:

exec 2>>/tmp/async-error.log

?

Let me know if any errors appear in the log when the problem occurs.

Interesting, it indeed looks like the async worker (zpty) has died, for some reason 😕.

I just realized, since you’re using antibody, you might already have been running part of the #454 PR (e.g. the zsh-async update, or master branch) which would’ve killed the worker in case of an error. The second part of #454 would allow the worker to re-start on next prompt.

One thing that stands out from your bundles.txt is zsh-autosuggestions. It has caused me some problems in the past. It also uses zpty but creates / destroys its instance constantly (vs. long-running instance in zsh-async). If you can try to reproduce with it disabled, that would be good info as well.

I’ll have to get back to you on this after the holidays, have a great one!