-
Notifications
You must be signed in to change notification settings - Fork 54
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
[WIP] improve(relayer): Improve resilience against non-updated SpokePoolClient #1837
base: master
Are you sure you want to change the base?
Conversation
// Some SpokePoolClients have not updated. Filter out the ones that are not updated to avoid upsetting the | ||
// BundleDataClient. | ||
let droppedSpokePools: string[] = []; | ||
spokePoolClients = relayerClients.spokePoolClients = Object.fromEntries( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nb. There are a few scenarios to test with this and I haven't made it that far, but this may not be the only change required. We should also consider whether these chain IDs should be removed from configured origin/destination chains, and possibly other configurables.
The existing limit of 10 loops was somewhat imprecise and was too short as observed in production. This would occasionally trigger asserts in the BundleDataClient because it requires all SpokePoolClient instances to be updated. Instead, permit up to 60 seconds before proceeding.
The BundleDataClient asserts that all SpokePoolClient instances have been updated. Ideally it could handle a non-updated SpokePoolClient, but in advance of that, filter the relayer's set of SpokePoolClients to exclude any that have not been updated after some defined time period.
5c2a4f7
to
bdc2563
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the proposer/disputer to work, all spoke pool clients must be updated. Otherwise we'll always create in valid bundles and worst case send disputes. Why would this be a valid fix?
The BundleDataClient asserts that all SpokePoolClient instances have been updated. Ideally it could handle a non-updated SpokePoolClient, but in advance of that, filter the relayer's set of SpokePoolClients to exclude any that have not been updated after some defined time period.