-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
test_read_line fails randomly #70
Comments
Before I changed the test expect_any. That would intermittently fail, giving "HiHi" instead of "Hi\r\n". I was able to reproduce that one locally. |
This bug is super annoying. I don't know what to do to reproduce it. I tried to run it directly on my machine, inside an Ubuntu 20.04 VM, as well as trying to run it inside an Ubuntu 20.04 container, looping 1000x each, and it never reproduced for me. It must be something that's being caused by some configuration in the test env itself, possibly how it captures the output. I'll try to read into the TTY configuration parameters, maybe it something pops up. |
I will play around a bit in #75 ... lets see. |
Looking at https://github.com/rust-cli/rexpect/blob/master/src/process.rs#L117, I think it would be better expressed as
I don't think it should make a difference, |
I was unable to reproduce the issue on my own. So far the only time it showed up is in https://github.com/philippkeller/rexpect/actions/runs/3060626462/jobs/4939368842, for PR #47.
I've reviewed the code involved in this test, but there was nothing obvious that could lead to such an issue. What I expected was that there's some sort of race condition where
Session::read_line
starts reading before the\n
is available, and so it ends up reading the string once, stopping because it can't match and then reading again, butNBReader
looks like it would correctly accumulate characters into the buffer and the whole operation is retried until the match is found in the buffer.The text was updated successfully, but these errors were encountered: