Skip to content
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

add starknet_estimateMessageFee endpoint #100

Merged
merged 3 commits into from
Jul 6, 2023
Merged

Conversation

ArielElp
Copy link
Collaborator

@ArielElp ArielElp commented May 29, 2023

This change is Reviewable

"name": "message",
"description": "the message's parameters",
"schema": {
"$ref": "#/components/schemas/FUNCTION_CALL"
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be more precise if we did not reuse FUNCTION_CALL here? Just similar to how there are separate types for the L1 handler call and the function call in cairo-lang: CallFunction and CallL1Handler

For example reusing calldata in FUNCTION_CALL for storing the payload of the L1 message sounds a bit like a hack to me...

Copy link
Collaborator Author

@ArielElp ArielElp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 of 1 files at r2.
Reviewable status: all files reviewed (commit messages unreviewed), 1 unresolved discussion (waiting on @kkovaacs)


api/starknet_api_openrpc.json line 548 at r1 (raw file):

Previously, kkovaacs (KOVACS Krisztian) wrote…

Wouldn't it be more precise if we did not reuse FUNCTION_CALL here? Just similar to how there are separate types for the L1 handler call and the function call in cairo-lang: CallFunction and CallL1Handler

For example reusing calldata in FUNCTION_CALL for storing the payload of the L1 message sounds a bit like a hack to me...

added a MSG_FROM_L1 type to distinguish this from function call and not use calldata

"required": true
},
{
"name": "sender_address",
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't sender_address redundant now that from_address is part of MSG_FROM_L1?

Copy link
Collaborator Author

@ArielElp ArielElp left a 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: all files reviewed, 2 unresolved discussions (waiting on @kkovaacs)


api/starknet_api_openrpc.json line 553 at r2 (raw file):

Previously, kkovaacs (KOVACS Krisztian) wrote…

Isn't sender_address redundant now that from_address is part of MSG_FROM_L1?

Correct, fixed

Copy link

@kkovaacs kkovaacs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Reviewed 1 of 1 files at r3, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @ArielElp)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants