[BUG][RACE CONDITION] fzf returns the first candidate even though another candidate is chosen

[NightMachinery]

• [x] I have read through the manual page (man fzf)
• [x] I have the latest version of fzf
• [x] I have searched through the existing issues

Info

• OS
  • [ ] Linux
  • [x] Mac OS X
  • [ ] Windows
  • [ ] Etc.
• Shell
  • [ ] bash
  • [x] zsh
  • [ ] fish

Problem / Steps to reproduce

I have tried debugging https://github.com/Aloxaf/fzf-tab/issues/206 extensively, and ultimately, it seems that there is a race condition in fzf that sometimes causes it to just return the first input candidate, even if another candidate is chosen. It's extremely hard to reproduce reliably, and I only encounter it with fzf-tab, but it does seem that the bug is with fzf.

The most compelling piece of evidence that the bug is with fzf is that the first line which contains the user query (because of --print-query) is ma, but fzf has returned \C-@.gdk-pixbuf-post-link.sh\C-@, which does not contain either of these characters. The race condition can be alleviated by first cleaning /dev/tty like so:

_ftb_query="${_ftb_query}$(command gdd bs=1G count=1 status=none iflag=nonblock < /dev/tty 2>/dev/null)" || true

fzf --query="$_ftb_query" ...

But there is still a race condition, and fzf still sometimes returns the first candidate instead of the chosen one.

I know this bug report kind of sucks and is not really reproducible (the bug seems to depend on a lot of moving machinery, e.g., I don't think it happens on Linux machines, and it happens randomly on my macOS machine), but you know your code base the best, perhaps you can have some idea what is wrong?

Thanks!

[alvarosevilla95]

@NightMachinery I believe I am having this issue as well, are you still experiencing it?

[NightMachinery]

@alvarosevilla95 commented on Sep 23, 2022, 5:46 PM GMT+3:30:

@NightMachinery I believe I am having this issue as well, are you still experiencing it?

Yes.