-
Notifications
You must be signed in to change notification settings - Fork 230
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
multichain-e2e: minimize ci flakes #9815
Comments
A recent motivating failure can be found here: https://github.com/Agoric/agoric-sdk/actions/runs/10154140014/job/28078772380?pr=9735#step:12:1574. The condition we are waiting for is staking rewards to become available after delegating. This failure only happens in one of the scenarios (chains) which suggests we need to increase the retry attempts/interval logic for this particular condition. |
- effectively, increases the total timeout window from 21 seconds to 40 seconds - see #9815 (comment) for details
- effectively, increases the total timeout window from 21 seconds to 40 seconds - see #9815 (comment) for details
- effectively, increases the total timeout window from 21 seconds to 40 seconds - see #9815 (comment) for details
refs: #9815 ## Description - allow `retryUntilCondition` callers to override default `RetryOptions = { maxRetries?: number; retryIntervalMs?: number; }` parameter - increase attempts and retry interval for "staking rewards available" condition in `stake-ica.test.ts`. ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations n/a ### Testing Considerations The goal of this PR is reduce observed CI flakes. ### Upgrade Considerations n/a
More recently, we are seeing failures for the makeAccount step (the first part of most flows):
Tying these to swingset logs, I see:
This seems to indicate we should have an offer result in ~9 seconds. The default timeout for Additional relevant context - with #9927, the first call to |
- effectively, increases the total timeout window from 21 seconds to 40 seconds - see #9815 (comment) for details
refs: #9815 ## Description Ensures we are passing `controllerConnectionId`, and not `hostConnectionId`, to `provideICQConnection`. _Was previously passing in CI since there's a 50/50 chance controllerConnectionId will equal hostConnectionId._ ### Security Considerations n/a ### Scaling Considerations n/a ### Documentation Considerations n/a ### Testing Considerations Addresses a "flake" that's really a bug. ### Upgrade Considerations n/a, unreleased code
Closing as a dupe of #9934 |
What is the Problem Being Solved?
When performing integration testing with networked applications, making all the sync points explicit and reliable is particularly challenging. Nonetheless, strategies can be employed to limit flakiness. In its current form this issue is intended to be a catch-all for flakes related to multichain-testing and the Multichain E2E CI Job.
The main retry mechanism that's current employed is a rudimentary retryUntilCondition helper that attempts
maxRetries
onretryIntervalMs
.Description of the Design
Security Considerations
Scaling Considerations
Test Plan
Upgrade Considerations
The text was updated successfully, but these errors were encountered: