[API] Fix unreliable test
"Update priority" tests fail occasionally.
1) Failure: UpdatePriorityTest#test_priority_0_but_should_be_>0 [/home/ci-jenkins/.jenkins-slave/workspace/developer-run-tests-services-api/services/api/test/unit/update_priority_test.rb:20]: Expected 0 to be < 0.
Possible explanation: if a background update task (
UpdatePriority.run_update_thread(), started from an after_commit callback in a previous test) is still running when the test case does an explicit inline call to
UpdatePriority.update_priority(), the inline call fails to get the lock, and returns immediately. But the background task's updates do not necessarily incorporate the latest priority updates, and even if they do, the resulting updates are not necessarily committed before the test case checks for them.
- Don't start the background update thread in the test environment.
- Pass a "block if needed" flag to update_priority(), so the test case works even when background tasks are running.
#10 Updated by Tom Clegg about 2 months ago
On second thought, disabling the background thread (and updating synchronously instead) in test cases seems undesirable: it would prevent all tests (even other components' integration tests) from experiencing async behavior.
A blocking flock() doesn't work: the background task sometimes gets the lock, then does a postgresql statement that blocks to wait for the main thread to commit/rollback. If the main thread then waits for the lock before (instead of) committing, everyone deadlocks in a way that postgresql can't detect.
Instead, solved by just skipping the lock when running "update priority" from the test case.
#12 Updated by Lucas Di Pentima about 2 months ago
I tried to make
master fail by running
update_priority_test.rb repeatedly on my local machine but wasn't able to reproduce the flaky behavior, even running the entire unit test suite several times.
I think it would be useful to add a comment on
noblock's use, for posterity. Apart from that, it LGTM.