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

1.x "Error: Number can only safely store up to 53 bits" on batch getTransaction #6241

Closed
nickbar86b opened this issue Jun 28, 2023 · 5 comments
Labels
1.x 1.0 related issues Bug Addressing a bug Stale Has not received enough activity

Comments

@nickbar86b
Copy link

nickbar86b commented Jun 28, 2023

Hello,
we are using web3 eth.getTransaction function to batch fetch transaction data using eth.BatchRequest();.
However, in web3-core-helpers the outputTransactionFormatter is throwing "Error: Number can only safely store up to 53 bits" when is trying to parse gas value for BNB chain.
Here is a tx example: 0x3e005e4ef863873682e028a3f500ee575474ded431edc09ee70e7e3c4e981c6a
and the gas that is passed is
gas: '0x7fffffffffffffff'

Expected behavior

to properly parse the value

Actual behavior

throws Error: Number can only safely store up to 53 bits

Environment

Web3 version 1.7.5

@nickbar86b
Copy link
Author

FYI the error persists even when we upgrade to v1.10

@nickbar86b nickbar86b changed the title "Error: Number can only safely store up to 53 bits" on batch getTransaction 1.x "Error: Number can only safely store up to 53 bits" on batch getTransaction Jun 28, 2023
@spacesailor24 spacesailor24 added Bug Addressing a bug 1.x 1.0 related issues labels Jun 28, 2023
@spacesailor24
Copy link
Contributor

Hi there, thank you for reporting this issue - it's actually a longstanding known issue with 1.x. #5845 was merged to address this issue, but I don't see how you'd be able to pass hexFormat to the formatter here

We did completely fix this issue in the latest version of web3, version 4.x though. Numbers are now formatted as BitInts unless otherwise specified by the user

@nickbar86b
Copy link
Author

I understand that in version 4 is resolved and we do plan to migrate ASAP but it is not straight forward and ideally we would like to have enough time to do it properly. A fix on this would give us that time. I wonder if gas can be moved into the if(hex) block or even if we treat the gas as a <string | number> instead; when the number is too big would temporarily fix the issue 🤷

@spacesailor24
Copy link
Contributor

#5845 is supposed to keep gas as a hex string if hexFormat is true, I just don't think you have access to that parameter as a user of the lib - We'll be working on fixing that if that's the case

A little off topic, but when you guys do decide to migrate to 4.x, if you could share how it went, the good, bad, and ugly, we'd really appreciate it. We tried to limit the breaking changes, so it'll be nice to know what can still be improved upon and how we might be able to make the experience of migrating more straightforward

@github-actions
Copy link

github-actions bot commented Oct 5, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions. If you believe this was a mistake, please comment.

@github-actions github-actions bot added the Stale Has not received enough activity label Oct 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.x 1.0 related issues Bug Addressing a bug Stale Has not received enough activity
Projects
None yet
Development

No branches or pull requests

2 participants