-
Notifications
You must be signed in to change notification settings - Fork 17
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
improve(BundleDataClient,SpokePoolClient): Log about duplicate events and delete getLatestProposedBundleData
#884
Conversation
We want to know when these events happen but we currently believe this is possible with the Indexed spoke pool client so we shouldn't throw.
getLatestProposedBundleData
should never load data from scratch
(d) => d.transactionHash === deposit.transactionHash && d.logIndex === deposit.logIndex | ||
) | ||
) { | ||
throw new Error("Duplicate deposit in bundleDeposits"); |
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.
Can we add a log message here to identify the relevant deposits? That will speed up debugging time significantly if we're able to isolate them.
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.
getLatestProposedBundleData
should never load data from scratchgetLatestProposedBundleData
should rarely load data from scratch
getLatestProposedBundleData
should never load data from scratchgetLatestProposedBundleData
@@ -431,52 +438,6 @@ export class BundleDataClient { | |||
}, toBN(0)); | |||
} | |||
|
|||
private async getLatestProposedBundleData(): Promise<{ bundleData: LoadDataReturnValue; blockRanges: number[][] }> { |
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.
We no longer need these functions in across-protocol/relayer#2085
if ( | ||
slowFillRequest.blockNumber >= destinationChainBlockRange[0] && | ||
_canCreateSlowFillLeaf(matchedDeposit) && | ||
!_depositIsExpired(matchedDeposit) |
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.
Side note: For a future optimisation, I wonder if this could also exclude slow fills that will be unfillable based on the fillDeadline and the challenge window required at the time of the proposal. Not sure if there are chicken and egg problems there though, since the challenge window could be modified up or down whilst the proposer is building a proposal. It would however be a way of returning deposit refunds to users faster, because the slow-fill that is ultimately unfillable is both an unfortunate use of capital as well as bad UX because the user has to wait for 2 bundles to get their repayment.
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.
I don't think we can do this because of this non-determinism:
since the challenge window could be modified up or down whilst the proposer is building a proposal
We just don't know which block number this bundle will be proposed. Theoretically the mainnet bundle end block could be hours before the proposal lands
src/clients/HubPoolClient.ts
Outdated
return ( | ||
executedLeaf.blockNumber <= block && | ||
executedLeaf.chainId === chain && | ||
executedLeaf.l1Tokens.map((l1Token) => l1Token.toLowerCase()).includes(l1Token.toLowerCase()) |
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.
This comparison sticks out to me. l1Token
as passed into the function is overridden within the Array.call()
closure. Additionally, l1Token
is a string in either case, and String.includes()
reverts to checking for substrings, rather than a complete match.
executedLeaf.l1Tokens.map((l1Token) => l1Token.toLowerCase()).includes(l1Token.toLowerCase()) | |
executedLeaf.l1Tokens.some((token) => token.toLowerCase() === l1Token.toLowerCase() |
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.
thats a good point, though I don't think the .map result matters since the map returns the modified array right? (which is then thrown away)
src/clients/HubPoolClient.ts
Outdated
executedLeaf.chainId === chain && | ||
executedLeaf.l1Tokens.map((l1Token) => l1Token.toLowerCase()).includes(l1Token.toLowerCase()) | ||
); | ||
}) as ExecutedRootBundle; |
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.
Is this to ward of an ...is potentially undefined
warning? Is it still necessary if the above change is made?
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.
Good call, this is an improvement: 329d44c
This reverts commit 7264854.
Co-authored-by: Paul <[email protected]>
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.
LGTM!!
* improve: Use optimized version of `getLatestPoolRebalanceRoot` Improves relayer and monitor performance by loading more data from arweave optimistically Depends on across-protocol/sdk#884 * lint * Update Monitor.ts * Update InventoryClient.ts * Update InventoryClient.ts * Update InventoryClient.ts * Update InventoryClient.ts * Update InventoryClient.ts * update * use token balanceOf as fallback * revert balanceOf call * rename funcs to internal * update * improve: Make "new"/"raw" gas price oracle the default * Update gas scalers * lint * Update package.json Co-authored-by: Paul <[email protected]> * Update package.json --------- Co-authored-by: Paul <[email protected]>
To be paired with across-protocol/relayer#2085 in order to speed up relayer marginally when pending bundle data is not yet available on Arweave. Also adds safety checks to BundleDataClient in case there are duplicate events