You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix flaky test TestActionDispatcher/Cancel_queued_action (#5364)
* Fix flaky test `TestActionDispatcher/Cancel_queued_action`
Here's the reason the test was flaky.
The flaky `queueAssertExpectations(t)` call asserts that
the queue's functions `DequeueActions` and `Save` functions are called.
These functions are indeed called during the `Dispatch` function call, but only after cancel actions are dispatched.
The test structure was the following:
1. Call the manager's `Dispatch` method in a goroutine.
2. Wait for the registered handler's `Handle` method to be called.
3. Assert that the queue's methods have been called.
Since the queue's methods are called during the `Dispatch` method AFTER the `Handle` method is called
for the Cancel action, the queue assertions may or may not succeed, depending on their timing.
To fix this, I have restructured the test to:
1. Call the `Dispatch` method in a goroutine.
2. Wait for the `Dispatch` method to end by waiting on the `dispatchCompleted` channel.
3. Confirm that the `Dispatch` method didn't instead block on the errors channel, which would indicate that the dispatcher dispatched an action other than the Cancel action (dispatcher never puts anything on the errors channel for dispatched Cancel actions).
4. Assert that `Handle` has been called and that the queue's methods have been called. At this point, the queue assertions are not prone to timing, as we have waited for the `Dispatch` method to complete.
* Remove unnecessary handler registration
This handler is already registered as default.
* Narrow down mock parameters
Replaces `mock.Anything` parameters with specific variables.
0 commit comments