-
-
Notifications
You must be signed in to change notification settings - Fork 716
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cli_send_*
tests in zellij_server
fail when running on too many threads
#1929
Comments
What are the failures you're getting? |
Usually looks something like this:
The "new snapshot" is always "0". |
This is a race. My guess would be that we're getting one less snapshot because we quit before the last render/update or some such. It's not significant for the test and can be fixed by only asserting the specific event we're looking for was received (in this case it would be the focus previous pane event). I'm pretty sure all of these are something like that. |
I noticed that the tests in
zellij_server
, when run fromcargo make
, started failing on my machine with one of the recent changes inmain
. I haven't yet bothered to track down the exact change that introduced this.The symptom for me is that the following 16 tests inside
zellij_server
fail:When limiting the number of CPU threads to use with e.g.
taskset
, less tests will fail. When giving 6 threads tocargo make
, all tests pass on my machine. This also explains why the CI doesn't fail, because IIRC that only has 3 threads available for x86 Ubuntu workers. The command I have to use is:As far as I could determine, this doesn't seem to be an error from shared global state. However, all these tests use
insta
to compare snapshots, and I don't know how insta works, so it may well be caused by races in global states of some sort. I tried the following to alleviate race conditions:rusty_fork
to fork out the tests into a more isolated environmentMutex
to the tests so simulating the sending from CLI doesn't happen in parallel any longerNone of these made the problems go away. One solution would be to limit the number of test threads in
cargo make
, but I'm wondering whether I'm the only person experiencing this? I also triedcargo clean
repeatedly in case it was caused by some old artifacts messing with the tests, but that hasn't changed the situation for me.The text was updated successfully, but these errors were encountered: