StopAtEOF is racy #67
Labels
bug
Something isn't working
Comments
github-merge-queue bot
pushed a commit
to pulumi/pulumi
that referenced
this issue
Apr 3, 2024
The library we're using unfortunately has a race condition that's especially worse when using polling to check for new changes of the file. Avoid this racyness by sleeping for a bit for now, but really this should be fixed upstream ideally. I opened a upstream issue for this in nxadm/tail#67. I think we should merge this in the meantime, as it makes this work, even though it's very hacky. I tested this in #15853, where I could no longer reproduce the failure we've seen before. Fixes #15659 Fixes #15235
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If you sent an issue/PR to hpcloud, you can have a look at
this meta issue tracking issues
and PRs of the dormant upstream. However, as the code bases diverge the
issue may have been solved already.
Describe the bug
The
StopAtEOFfunction can sometimes stop tailing the file before we actually encounter an EOF. In particular, when using the polling function for checking for file changes, we might select this tail.Dying channel here first before the poller gets another chance to notify us of new changes, which I believe makes us then return here, even though we should probably be waiting for another poll cycle.Expected behaviour
The library checks again for new changes in the file after
StopAtEOFis reached.To Reproduce
This is a bit awkward to reproduce, since it's based on racyness. However tailing a file that's being written to in short intervals, and calling
StopAtEOFmight not return all data before exiting.Additional context
I'd be happy to contribute a PR for this, but probably won't have the time to do so before next week.
The text was updated successfully, but these errors were encountered: