-
Notifications
You must be signed in to change notification settings - Fork 30
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
fix: l2-to-l1 messaging #371
base: main
Are you sure you want to change the base?
Conversation
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 should effectively solve l2>l1 messaging @shamsasari
Should I wait for the merge into |
.flat_map(|call_info| call_info.iter()) // flatmap over the roots' recursive inner call infos | ||
} | ||
|
||
let messages_sent = recursive_call_info_iter(res) |
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.
why not do these 2 operations at the same time?
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.
sure okay
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.
it would be a bit messy with flat_map to unzip the iterator into two collections like this, do you have a suggestion that would look good?
i can't come up with a cleaner way than two iterations here and i don't think the perf implications are very important
As I mentioned offline, this PR unfortunately doesn't make the Kakarot I'm not sure what to make of this. Is this behaviour somehow expected of a Starknet node? |
Pull Request type
What is the current behavior?
Receipt is produced wrong
What is the new behavior?
We need to do the same thing for both events and l2-to-l1 messages: iterate recursively into the callinfos.
We already had a function to do that for events, but it looked kind of ugly - so I replaced it with the recursive iterator that blockifier provides. I moved events to use that too.