-
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
feat: Propagate invalid fill reasons to caller #486
Conversation
This change provides additional information to the caller of queryHistoricalDepositForFill(). In the case that a fill is not found, a cause code is associated: - 0: The deposit ID was invalid for the SpokePool (i.e. cannot exist). - 1: The deposit ID was valid, but it wasn't found within scraped data (i.e. maybe the RPCs aren't serving it in eth_getLogs() requests). - 2: The deposit ID was valid, but one or more fields in the corresponding deposit were mismatched (i.e. the fill was invalid). This is most interesting for case (1), where there's a reasonable indication that the deposit should be held within the SpokePoolClient's deposit map, but isn't. This indirectly acts like a qualitative measure for RPC provider responses and will allow the upper layers to dynamically revert to more conservative behaviour.
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 is a great solution. Do you want to add unit tests for the other InvalidDeposit codes in this PR or a follow up? I think it's ok to do a follow up since this updates all existing logic
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!
This change provides additional information to the caller of queryHistoricalDepositForFill(). In the case that a fill is not found, a cause code is associated:
This is most interesting for case (1), where there's a reasonable indication that the deposit should be held within the SpokePoolClient's deposit map, but isn't. This indirectly acts like a qualitative measure for RPC provider responses and will allow the upper layers to dynamically revert to more conservative behaviour.