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

Implement TryFrom<Transaction> for TransactionInfo #662

Merged
merged 5 commits into from
May 2, 2024

Conversation

tcoratger
Copy link
Contributor

No description provided.

block_number: tx.block_number,
base_fee: match tx.transaction_type {
Some(tx_type) => match tx_type.try_into() {
Ok(TxType::Legacy) | Ok(TxType::Eip2930) => tx.gas_price,
Copy link
Member

Choose a reason for hiding this comment

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

is this behavior correct? wouldn't it be the block base fee regardless of tx content?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would say yes because it is precisely in the situation where we do not have information on the block but only on the tx. So we try to reconstruct the base fee as a function of the transaction type with the available information.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, but it produces the wrong output. Like whatever else we know, we know that this output is not the basefee. I'm reluctant to merge code that we know to be incorrect

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we can just put a None to say that we don't know precisely what is the base fee as we just have information about the transaction, wdyt?

Copy link
Member

Choose a reason for hiding this comment

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

i would prefer that, as it guarantees we give no bad output. However, i don't know what this type is for so i can't say that the incorrect output is not expected 😅 What is the motivating use case of this PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

In fact I realized that in tracing to trace a transaction, we quite often do the conversion Transaction to TransactionInfo and so I said to myself that it was useful to have a try_from here but it's true that we can set to None and then fill with the base fee coming from the env block.

Just pushed that, tell me if it's ok for you :)

Copy link
Member

Choose a reason for hiding this comment

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

In fact I realized that in tracing to trace a transaction, we quite often do the conversion Transaction to TransactionInfo and so I said to myself that it was useful to have a try_from here but it's true that we can set to None and then fill with the base fee coming from the env block.

Gotcha. makes sense. I think that now we have no errors tho, so we can make this From<&Transaction> for infallible conversion :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ouuups just fixed

@prestwich prestwich merged commit da08a68 into alloy-rs:main May 2, 2024
24 checks passed
ben186 pushed a commit to ben186/alloy that referenced this pull request Jul 27, 2024
* impl TryFrom<Transaction> for TransactionInfo

* Update crates/rpc-types/src/eth/transaction/common.rs

Co-authored-by: evalir <hi@enriqueortiz.dev>

* fix base fee

* fix comment

* From<&Transaction>

---------

Co-authored-by: evalir <hi@enriqueortiz.dev>
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.

3 participants