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.

Sign up for GitHub

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

Jump to bottom

Make the tx_spammer additional service start working with our client #1026

Closed
rodrigo-o opened this issue Oct 30, 2024 · 0 comments · Fixed by #1027
Closed

Make the tx_spammer additional service start working with our client #1026

rodrigo-o opened this issue Oct 30, 2024 · 0 comments · Fixed by #1027
Assignees
@rodrigo-o
Labels
bug Something isn't working

Comments

@rodrigo-o
Copy link
Collaborator

After solving #847 we were able to be the first node in the network_params.yaml file, and so, being the target of the transaction spammer. The node was working as part of the kurtosis devnet and assertoor test went through but the tx spammer immediately stops with:

No seed provided, creating one
Internal Error: Could not resolve block number
sending at f93ee4cf8c6c40b329b0c0626f28333c132cf241
error getting pending nonce; could not airdrop: Internal Error: Could not resolve block number

The objective of this issue is having the tx spammer running, not solving every issue that appears on the runs, if we are able to get an initial transaction going through, then we can start creating new issues for specific errors encountered by the fuzzer.
@rodrigo-o rodrigo-o added the bug Something isn't working label Oct 30, 2024
@rodrigo-o rodrigo-o self-assigned this Oct 30, 2024
@rodrigo-o rodrigo-o changed the title Make the tx_spammer additional service start working Make the tx_spammer additional service start working with our client Oct 30, 2024
@rodrigo-o rodrigo-o mentioned this issue Oct 30, 2024
Merged
github-merge-queue bot pushed a commit that referenced this issue Oct 31, 2024
@rodrigo-o
fix(l1): made the tx-spammer work with our node (#1027)
acd0365 
**Motivation**

Have the tx spammer running instead of immediatly shutting down when we
are the first node in the devnet setup.

**Description**

This PR tackled a couple of issues until we were able to process an
initial transaction, (they are small changes):
- We were returning an error on `eth_getTransactionCount` when we either
didn't have a `latest` block before genesis or at any point when we
don't have `pending` blocks. The solution in this case was returning
`0x0` in those cases.
- When requesting `eth_getTransactionCount` on `pending` after some
transaction went through we were defaulting to `0x0`, it appears that
the idea is to default to the `latest` in those case which make sense.
- There were a missing filter that made the node panic when building
payloads for transactions with fees lower than the base_fee_per_gas,
this generated that those kind of transactions stopped the node's
ability to build blocks when they were in the mempool, we made a quick
workaround in this PR, but will remove it in favor of #1018

Closes #1026
h3lio5 pushed a commit to h3lio5/lambda_ethereum_rust that referenced this issue Oct 31, 2024
@rodrigo-o @h3lio5
fix(l1): made the tx-spammer work with our node (lambdaclass#1027)
202fff3 
**Motivation**

Have the tx spammer running instead of immediatly shutting down when we
are the first node in the devnet setup.

**Description**

This PR tackled a couple of issues until we were able to process an
initial transaction, (they are small changes):
- We were returning an error on `eth_getTransactionCount` when we either
didn't have a `latest` block before genesis or at any point when we
don't have `pending` blocks. The solution in this case was returning
`0x0` in those cases.
- When requesting `eth_getTransactionCount` on `pending` after some
transaction went through we were defaulting to `0x0`, it appears that
the idea is to default to the `latest` in those case which make sense.
- There were a missing filter that made the node panic when building
payloads for transactions with fees lower than the base_fee_per_gas,
this generated that those kind of transactions stopped the node's
ability to build blocks when they were in the mempool, we made a quick
workaround in this PR, but will remove it in favor of lambdaclass#1018

Closes lambdaclass#1026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rodrigo-o rodrigo-o

Labels
bug Something isn't working
Projects
ethrex_l1
Status: Done
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(l1): made the tx-spammer work with our node lambdaclass/ethrex
1 participant
@rodrigo-o