-
Notifications
You must be signed in to change notification settings - Fork 132
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
Repeated test error: Possible EventEmitter memory leak detected #2783
Labels
test
Creating/improving test automation
Comments
I do have a hint at what this might be. We mock the IPC calls between the main process and the renderer process in tests. They probably don't get torn down between tests or reset. |
Verified in Zui commit de25266. The concerning messages are gone from the
Here's a look at the full/tidier
Thanks @jameskerr! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Repro is with Zui commit b7dbd16 (associated with #2759).
While debugging other Zui test failures recently, I've been distracted by this big burst of errors that consistently appears when I run
yarn test
.This doesn't make the tests fail and for all I know they could be quite benign. However, their volume and mention of a possible memory leak gave me reason to be concerned that there could be an actual problem behind them and that this could somehow be contributing to the failures we see more often when CI tuns in GitHub Actions since those Runner hosts are typically quite resource constrained. If investigations find that there's not a real bug here, then maybe we could find a way to silence them or present them as harmless. I don't personally know anything about
EventEmitter
but my brief web search led me to this link where the folks posting in the thread caution that just increasing the limit is often not the appropriate course of action and that there very likely is a legit root problem that's worth fixing.Note that the commit b7dbd16 where I've just reproduced the issue is associated with #2759, which was a major refactor. I narrowed down through binary search that this was the point at which this message started appearing so frequently. At commit 7363dee that came right before I only see one of these messages.
The text was updated successfully, but these errors were encountered: