IPC provider subscription randomly not working
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
I have a full node on my pc which works perfectly and I'm using web3js IPC Provider to subscribe to pending transactions.
In a random moment, more or less once every two days, the IPC stop to send pending transactions without any error and it's not a node problem as I'm constantly monitoring it.
I'm using the following code to monitor the subscription, but only the connected and data event works for now.
web3.eth.subscribe('pendingTransactions',(error, result) => {
if(error) console.error(error);
})
.on("connected", async function () {
console.log("IPC CONNECTED")
})
.on("close", async function () {
console.log("IPC CLOSE")
})
.on("error", async function (e) {
console.log("IPC ERROR")
})
.on("end", async function () {
console.log("IPC END")
})
.on("timeout", async function () {
console.log("IPC TIMEOUT")
})
.on("data", async function (txHash) {
console.log(txHash)
})
Expected Behavior
I expect an error event so I can manage this edge case or a better configuration of the IPC provider with timeout and retry config such as ws and http provider.
Steps to Reproduce
Can't find a way to reproduce it.
Web3.js Version
1.6.1
Environment
- Operating System: Windows 10
- Node.js Version: 16.13.1
- NPM Version: 8.1.2
Anything Else?
No response
@francesco-clementi-92 That's merely impossible to reproduce on our side if that effect in longer run.
We have a configuration listener on timeout, if that happens the connection must throw error.
https://github.com/ChainSafe/web3.js/blob/8783f4d64e424456bdc53b34ef1142d0a7cee4d7/packages/web3-providers-ipc/src/index.js#L105-L107
Can you try to debug it further on your side, by disconnecting your code temporarily or by removing the socket file while node is running.
Hi @nazarhussain ,
starting the IPC provider with a node that is syncing (so not receiving pending transaction event), I have the same problem.
No timeout or error event, even if it's successfully connected, I don't know if it's normal or not.
Do you know a way to disconnect the node without stopping it?
If not l'll try to test it asap.
No I don't think there is a straight forward way to do it. May be you can update your code to catch the error on higher scope, then try reconnect the IPC provider.
https://github.com/ChainSafe/web3.js/blob/8783f4d64e424456bdc53b34ef1142d0a7cee4d7/packages/web3-providers-ipc/src/index.js#L201
The problem is that there is no error to catch.
I found a way to replicate it, connect the IPC provider and run a subscription, then disconnect the computer from internet.
The subscription will be stucked with no error.
That's seems to be a real issue, but as per our priorities right now we will address it in 4.x rewrite.
Will manually test this in the Alpha release.
Pushing this testing out to Beta release
Hey team! Please add your planning poker estimate with ZenHub @avkos @jdevcs @luu-alex @nikoulai @spacesailor24
Please add your planning poker estimate with ZenHub @nazarhussain
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.
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.
https://eips.ethereum.org/EIPS/eip-1193#events our current providers should be in compliance with this.
I am having the same issue. It seems the subscriptions are randomly stopping without emitting the 'error' event. Here is how the subscription is created.
export function getSubscription(
chainId: number,
eventName: DystoEventName,
handler?: DystoLogHandler<typeof eventName>
): Subscription<Log> | undefined {
const network = getNetworkByChainId(chainId);
const subscription = network.web3.eth.subscribe(
"logs",
{
address: network.dystoWorldPortalContract.options.address,
topics: [getEventTopicSignature(eventName)],
},
(error, result) => {
if (!error) {
const eventObj = decodeLog(result, eventName, network);
if (handler) {
handler(eventName, eventObj);
}
}
}
);
subscribedEvents[
`${chainId}-${network.dystoWorldSpacesContract.options.address}-${eventName}`
] = subscription;
return subscription;
}
Here is an example of the eventListener for 'error'
purchasedEventSub.on("error", (data: Error) => {
Logger.error(
`Subscription error for ${purchasedEventName} event of the contract DystoWorldPortal on chain ${chainName} - chainId ${chainId}. Error: ${stringifyError(
data
)}`
);
});
Thank you for your attention. Let me add a little bit of details:
- this task was done only for the 4.x version of web3js
- You may have a provider error (not a subscription error). For example, a connection error should be in the event of the provider. According to EIP-1193 provider should have these types of events: message, connect, disconnect, chainChanged, accountsChanged. But in 1.x version of web3js we have only these events: message, open, error, close. To subscribe to provider events:
web3.provider.on('error',()=>{
// ...
})
web3.provider.on('close',()=>{
// ...
})
web3.provider.on('open',()=>{
// ...
})
web3.provider.on('message',()=>{
// ...
})
Or you can separately create provider and then pass it to web3
const Web3 = require("web3");
const provider = Web3.providers.WebsocketProvider('wss:/...')
const web3 = new Web3(provider)
provider.on('error',()=>{
// ...
})
I have one question, I can't seem to find this in the documentation. Why do the events not come with any parameters? I'll know the provider errored out, but not why.
Thanks for the help
If you use WebSocket as a provider error event will be the same as WebSocket connection produce. We use isomorphic WS. You can check events here for example, here are error event details for WS for the server. Also, you can check error codes here
If you have any questions please ask.