-
Notifications
You must be signed in to change notification settings - Fork 27
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
chore(blockifier,starknet_api): move l1handler to executable tx #1723
chore(blockifier,starknet_api): move l1handler to executable tx #1723
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @yair-starkware and the rest of your teammates on Graphite |
92fad74
to
dafdb36
Compare
Artifacts upload triggered. View details here |
dafdb36
to
2cae216
Compare
Artifacts upload triggered. View details here |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1723 +/- ##
===========================================
+ Coverage 40.10% 65.74% +25.64%
===========================================
Files 26 145 +119
Lines 1895 17839 +15944
Branches 1895 17839 +15944
===========================================
+ Hits 760 11729 +10969
- Misses 1100 5345 +4245
- Partials 35 765 +730 ☔ View full report in Codecov by Sentry. |
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.
Reviewed all commit messages.
Reviewable status: 0 of 7 files reviewed, 2 unresolved discussions (waiting on @giladchase, @noaov1, and @yair-starkware)
a discussion (no related file):
After looking into it again, I think we might have to add L1HandlerTransaction to the executable_transaction enum, because the transactin providers get_txs return type has to be consistent. I'm fine with adding it, even if the mempool can't return it. WDYT? @yair-starkware @noaov1 @giladchase
crates/blockifier/src/test_utils/struct_impls.rs
line 227 at r2 (raw file):
} pub trait CreateForTesting {
How about moving this impl also? Creating a trait just for a single impl block seems weird
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.
Reviewed 2 of 7 files at r1.
Reviewable status: 1 of 7 files reviewed, 2 unresolved discussions (waiting on @giladchase and @yair-starkware)
a discussion (no related file):
get_txs return type has to be consistent
I see that it is currently divided into two providers (one for Transaction and one for L1HandlerTransaction. Anyway, it can be consistent by defining a Transaction enum that contains an account transaction and an L1 handler. I think the separation is required (the execution flows are different).
WDYT?
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.
Reviewable status: 1 of 7 files reviewed, 2 unresolved discussions (waiting on @alonh5, @giladchase, and @noaov1)
a discussion (no related file):
Previously, noaov1 (Noa Oved) wrote…
get_txs return type has to be consistent
I see that it is currently divided into two providers (one for Transaction and one for L1HandlerTransaction. Anyway, it can be consistent by defining a Transaction enum that contains an account transaction and an L1 handler. I think the separation is required (the execution flows are different).
WDYT?
We talked about it in the meeting.
Each provider can return its own type and the blockifier adds another type which is an enum of both of them.
We convert executable_transaction
into the blockifier type anyways.
crates/blockifier/src/test_utils/struct_impls.rs
line 227 at r2 (raw file):
Previously, alonh5 (Alon Haramati) wrote…
How about moving this impl also? Creating a trait just for a single impl block seems weird
We don't have testing instances for the other types in SN_API so I don't want to introduce a new module just for that
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.
Reviewed 6 of 7 files at r1, 1 of 1 files at r2.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @giladchase, @noaov1, and @yair-starkware)
crates/blockifier/src/test_utils/struct_impls.rs
line 227 at r2 (raw file):
Previously, yair-starkware (Yair) wrote…
We don't have testing instances for the other types in SN_API so I don't want to introduce a new module just for that
You can add a cfg(test) over it
Previously, alonh5 (Alon Haramati) wrote…
It uses |
2cae216
to
46fb6bd
Compare
Artifacts upload triggered. View details here |
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.
Reviewed 2 of 2 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @giladchase, @noaov1, and @yair-starkware)
crates/blockifier/src/test_utils/struct_impls.rs
line 227 at r2 (raw file):
Previously, yair-starkware (Yair) wrote…
It uses
selector_from_name
which is defined in blockifier
Okay so leave it here. Can you turn it into a regular function please?
l1_handler_tx()
in a separate file like the other 3 txs
46fb6bd
to
a24007c
Compare
a24007c
to
a27848a
Compare
Artifacts upload triggered. View details here |
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.
Reviewable status: 3 of 9 files reviewed, 1 unresolved discussion (waiting on @alonh5, @giladchase, and @noaov1)
crates/blockifier/src/test_utils/struct_impls.rs
line 227 at r2 (raw file):
Previously, alonh5 (Alon Haramati) wrote…
Okay so leave it here. Can you turn it into a regular function please?
l1_handler_tx()
in a separate file like the other 3 txs
Done.
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.
Reviewed 2 of 5 files at r4, 4 of 4 files at r5, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @giladchase and @noaov1)
No description provided.