-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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.getBlock sometimes does not return at all; sometimes produces "TypeError: Cannot create property 'gasLimit' on string" #3573
Comments
I think I’ve solved it! The shared memory which is at the root of the issue is in the WebsocketProvider's First, some relevant points on how requests work in web3: when a request is sent (examples: eth_subscribe, eth_getLogs, eth_getBlockByNumber), the "toPayload()" method of web3-core-requestmanager/src/jsonrpc is asked to bundle it up into a request. As part of this bundling, it assigns a sequential numeric id ( The problem in the example code above is that there are multiple separate instances of the web3-core-requestmanager’s When the code above calls eth_getBlock for block numbers 4-8, it’s using node_modules/web3-core-requestmanager/src/jsonrpc.js (file paths relative to the project root). Those requests for information about blocks 4-8 become request numbers 1-5 respectively. However, previous to this, there are five other requests, which are using node_modules/@truffle/interface-adapter/node_modules/web3-core-requestmanager/src/jsonrpc.js (and NOT, as one might have guessed, node_modules/@truffle/contract/node_modules/web3-core-requestmanager/src/jsonrpc.js, which may start yet another sequence). In the example code above, those requests are: In this earlier list, requests 1-3 get a response back and are deleted from the responseQueue before the second set of requests is constructed, so there’s no conflict/overlap. However, requests 4 and 5 are still active in that responseQueue at the time the eth_getBlock requests with the same ids overwrites them. When a response comes in for the earlier request, it gets sent to the handler for the later request, and the handler for the later request is removed. Then, when the response for the later (eth_getBlock) request comes in to the WebsocketProvider, it gets ignored. To see which jsonrpc.js file is being used for which request, you can go to those files and change the starting messageId values in the different files to different values, like 30/50/70 for the three respective files. Set this line to The workaround is to make sure the Provider object used for contracts is different from the one used for the web3 object. That is, in the sample code above, change let provider = new Web3.providers.WebsocketProvider('ws://127.0.0.1:7545');
let web3 = new Web3(provider);
counterContract.setProvider(provider); to let web3 = new Web3(new Web3.providers.WebsocketProvider('ws://127.0.0.1:7545'));
counterContract.setProvider(new Web3.providers.WebsocketProvider('ws://127.0.0.1:7545')); which should close both this and #3568. |
Defensive programming per last sentence of paragraph 8 in web3#3573 (comment)
wow @wbt thanks for digging into this! |
Defensive programming per last sentence of paragraph 8 in #3573 (comment)
This is a follow-up to #3568 in which I attempt to provide a reproducible example for that Issue and wind up creating a reproducible example for a different issue which seems like it might be related.
Steps to reproduce the behavior (commands for command-line shell)
mkdir blockArrayTest
cd blockArrayTest
truffle init
npm init
[OK to accept defaults]truffle migrate --reset --network development
npm i @truffle/contract
npm i web3
node getEvents.js
Expected behavior
web3.eth.getBlock "Returns a block matching the block number or block hash."
The output should include these lines, missing the first two if
condition2
is used:Actual behavior
The expected lines about block 8 are absent. (I think the second half of this comment is related.)
When using
condition1
the output does NOT include the expected lines about block 7 and also includes the unexpected:Environment
npm -version
6.14.5node -v
v9.3.0As seen in start of output: Using web3 version 1.2.8
Windows 10, using PowerShell for commands
The text was updated successfully, but these errors were encountered: