-
Notifications
You must be signed in to change notification settings - Fork 5
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
Fix test-runner race conditions #269
Conversation
…create race conditions
Codecov ReportBase: 93.95% // Head: 93.97% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #269 +/- ##
==========================================
+ Coverage 93.95% 93.97% +0.02%
==========================================
Files 59 59
Lines 4928 4950 +22
==========================================
+ Hits 4630 4652 +22
Misses 298 298
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
You mentioned still seeing one test fail sometimes here but I couldn't reproduce this myself.
Thanks! I'll make an issue about it and then we keep looking out for it! |
Some of our tests use the underlying static schema provider which is a static mutable data store (due to a workaround for
async-graphql
). This mutable store is accessible across all test runner threads in parallel mode as they all run in the same process. To prevent overwriting data across threads (race condition) we have to run these test in serial.Read more: https://users.rust-lang.org/t/static-mutables-in-tests/49321
Background
This PR is blantantly stolen from #266 which is the in-depth research of @sandreae to find out where the race-conditions came from.
The following changes have been made in comparison to PR #266:
[#serial]
. It's fairly special-case and I can see how that same problem will come up in the future when we (and others) add new tests and forget to make them execute in serial. These comments will not necessarily prevent that but it's better than nothing maybe.I'm wondering if there's another way to tackle the issue in the future. We could have a mocked static schema store only for test environments which puts the data behind a randomized key which is set once per thread. Then all parallelly-running tests would have the schema store behind the same memory address, but access different areas inside of it.
Closes: #247
📋 Checklist
CHANGELOG.md