-
Notifications
You must be signed in to change notification settings - Fork 5k
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
eth.getTransaction sometimes never returns #3656
Comments
Here is a simplified set of reproduction steps that I hopes help illustrate the issue:
New file contracts/Counter.sol:
New file migrations/2_deploy_contracts.js:
New file migrations/3_increment_counter.js:
New file fetchHistory.js:
Set up Geth 1.9.10 to run a webSocket interface on port 8546 (or change the port number in fetchHistory.js). THEN:
If the migration is interrupted (e.g. because the Geth node is busy and gives an Invalid JSON RPC response: ""), you can restart the event-adding one with In my example, the counter value reached
while the expected repeating last line is one in which all three numbers match:
|
FYI, I dove all the way down to the W3CWebSocket and I don’t see any “onMessage” calls that web3 isn’t handling. |
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. |
Sample code:
I observe the issue when this is called many times in parallel, e.g. fetching several thousand events and then calling it for each transaction cited by the events. The number of times the success condition is reached, and which transactions it is reached for, seems to vary randomly but the number is typically around the 2-12 range. This remains the case even when I wait for a couple days (without adding any new web3 requests) to see if the response may be just very slow. Unfortunately I do not have easily shareable reliable reproduction steps, as the set of success varies randomly from run to run.
I am already using the workaround of #3573 so that is not an adequate solution.
Expected behavior
In general, I expect the success branch to be reached. If there is some error that the success branch will never be reached, I expect the error branch to be reached.
Actual behavior
In most cases, neither the error nor the success branch are ever reached.
Environment
Windows 10
Node 9.3.0, npm 6.14.5
web3 1.2.7
geth 1.9.10
The text was updated successfully, but these errors were encountered: