fix: Fix a couple of unit test timeout problems when run concurrently with coverage#39
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #39 +/- ##
==========================================
- Coverage 78.66% 78.66% -0.01%
==========================================
Files 472 472
Lines 67661 67661
Branches 10419 10419
==========================================
- Hits 53227 53223 -4
- Misses 10918 10921 +3
- Partials 3516 3517 +1 see 5 files with indirect coverage changes Continue to review full report in Codecov by Sentry.
🚀 New features to boost your workflow:
|
|
Traceback in Github CI |
|
(one example of) Traceback on my machine with twisted runners at (note: other runs at |
4606d06 to
a34507e
Compare
|
Largely my conclusion is that this is what was reported to me: a concurrency problem. I see two solutions: increase the timeout for that particular test or reduce the number of jobs being run in Github CI. Based on some(really loose) math, it looks like a timeout of 30 seconds allows all the database calls to write the lock and then handle all the sorted deferreds and database reads in the main reactor threadpool(see reactor.callFromThread()) EDIT: Found the pull request this came from: element-hq/synapse#16840 |
34a7928 to
1b7b96e
Compare
|
Looks like other than the worker lock tests, there was another test for redactions that was using 'real time' to judge for it's timeout. Since the unit tests don't operate on real time, but on the fake reactor time, that can clash when under heavier concurrency. Swapping it to the fake time on the test reactor seems to sort that out. |
b3b690b to
dfa1b0f
Compare
dfa1b0f to
e9d8966
Compare
Contains a partial revert of #39 where in test_lock_contention() of test_worker_locks.py the timeout of the test was bumped to 15 seconds to allow testing with 36 trial runner jobs. I just will not run 36 jobs any more instead
No description provided.