test(multichain-testing): stir
for no AVA timeout in long awaits
#10234
+145
−14
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
refs: #9934
Description
Reviewing the fact that AVA's "default timeout is 10 seconds", if no assertions are made during that timeout, AVA fails the test. The
multichain-testing
tests encounter this timeout when performing longawait
s, notable during sleeps or during waiting for retry conditions that may take a long time.Rather than attempting to solve this flake by trial-and-error moving AVA's
timeout
setting until the tests pass, this PR allows the longawait
s (sleep
,delay
, andretryUntilCondition
's operation) to "stir". That is, the test itself can specify a callback that will be invoked periodically when in a long "safe" await (that is, the await will already throw properly if there is an encountered problem, and the AVA assertion timeout just gets in the way). If thestir
callback contains a trivial AVA assertion, that will reset AVA's internal assertion clock to postpone failure by timeout.Security Considerations
n/a
Scaling Considerations
n/a
Documentation Considerations
n/a
Testing Considerations
A simple test of stirring while sleeping past the AVA timeout shows that this feature works. If this also helps avoid #9934, we should see fewer reports of flaky multichain-e2e tests.
Upgrade Considerations
n/a