-
Notifications
You must be signed in to change notification settings - Fork 1
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
STR-376: create the machinery around polling and execution of bridge duties v2 #293
STR-376: create the machinery around polling and execution of bridge duties v2 #293
Conversation
Codecov ReportAttention: Patch coverage is
@@ Coverage Diff @@
## master #293 +/- ##
==========================================
- Coverage 61.70% 61.02% -0.69%
==========================================
Files 209 207 -2
Lines 21449 21703 +254
==========================================
+ Hits 13235 13244 +9
- Misses 8214 8459 +245
|
05a46d9
to
e258a8e
Compare
@Rajil1213 this is ready for the first round of reviews. |
e258a8e
to
c090b4d
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.
I think all the pieces are there and some of the issues I pointed out could have been due to the APIs in bridge-sig-manager
and tx-builder
not being very clear in their intent.
The deeper refactoring that needs to be done here is to consolidate the deposit and withdrawal handlers together. It no longer makes sense to have them be separate because they do exactly the same thing but on different transactions. The separate transactions are created at a lower-level (in the sig-manager
and tx-builder
crates). So, the exec part only needs to worry about passing in the right parameters.
The more important role that the exec part plays should be about tracking the duty lifecycle from the point that a duty is received to the point that they are dispatched, calling all the relevant RPCs and maintaining information about itself (keys, index, etc.). It also needs to maintain a checkpoint (the L1 block height) up to which it has already seen duties. This can be used to pull in deposit duties as those are stored off-chain in a database by the rollup node. The implementation for this duty RPC is under way and I should have a draft PR ready in a couple of hours today or by tomorrow at the latest. The other withdrawal duty RPC behaves the same way but does not need a checkpoint because you always get the latest set of duties in the current rollup chain state.
I think there is enough refactoring work to be done here for the duty RPCs to not be a blocker but let me know if you're blocked on anything and we can collaborate some more on how to get both things done in parallel (agreeing on the RPC interface could be one).
d4fc7bd
to
ae9eec2
Compare
ae9eec2
to
8ca8223
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.
Structurally seems pretty good. Mostly some comments about the logging though.
8ca8223
to
840d444
Compare
Sorry @delbonis this was into heavy rebasing and overhaul. I had two "pair-coding" sessions with @Rajil1213 to get this in a proper state. I am afraid that you might have to review again, but it is MUCH more simpler and with less code than when you last reviewed. I did a bunch of cleanups and QoL improvements in the bridge message machinery, check if these changes are ok. |
840d444
to
d8ed865
Compare
I'll fix soon today the logging stuff, check the future-correct version of |
d8ed865
to
aed88ac
Compare
Yes, @Zk2u discussed applying the |
@delbonis and @Rajil1213 ready for another round. |
Looks like @Zk2u is working on doing some refactoring on top of this PR in #324 which has already been approved. Should we wait to review this PR until that's merged @storopoli as I can see a bunch of common files being changed there? |
The refactor is only to unify the handlers. |
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.
If the other comments have been resolved one way or another then this seems good to me.
aed88ac
to
91aaffa
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.
A few more nits and then, I think we are good to go
We will need more extensive automated testing for all of this but hopefully we can use the functional-tests
when we have the bridge client binary operational.
3afb64e
to
7ebcef5
Compare
@Rajil1213 I've added all your suggestions and will open a ticket for the unimplemented AlpenApi RPC call. |
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.
Left a few more comments after the merge
that I missed the last time around.
7ebcef5
to
4b9472a
Compare
4b9472a
to
0c813d1
Compare
0c813d1
to
96b2742
Compare
Okay. I'll keep an eye on the CI checks and will approve as soon as they pass. |
This can be a commit merge |
Description
The machinery around how the bridge client will query for duties from the CL,
delegate them to various handlers for their execution,
as well as the actually execute these duties within those handlers.
TODO:
Type of Change
Checklist
Related Issues
STR-376