web3.js icon indicating copy to clipboard operation
web3.js copied to clipboard

IPC provider subscription randomly not working

Open francesco-clementi-92 opened this issue 4 years ago • 11 comments

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 avatar Dec 28 '21 13:12 francesco-clementi-92

@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.

nazarhussain avatar Jan 06 '22 16:01 nazarhussain

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.

francesco-clementi-92 avatar Jan 06 '22 17:01 francesco-clementi-92

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

nazarhussain avatar Jan 06 '22 18:01 nazarhussain

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.

francesco-clementi-92 avatar Jan 06 '22 19:01 francesco-clementi-92

That's seems to be a real issue, but as per our priorities right now we will address it in 4.x rewrite.

nazarhussain avatar Jan 21 '22 10:01 nazarhussain

Will manually test this in the Alpha release.

mconnelly8 avatar Feb 08 '22 17:02 mconnelly8

Pushing this testing out to Beta release

mconnelly8 avatar Mar 22 '22 17:03 mconnelly8

Hey team! Please add your planning poker estimate with ZenHub @avkos @jdevcs @luu-alex @nikoulai @spacesailor24

mconnelly8 avatar May 17 '22 17:05 mconnelly8

Please add your planning poker estimate with ZenHub @nazarhussain

mconnelly8 avatar May 17 '22 17:05 mconnelly8

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[bot] avatar Jul 17 '22 00:07 github-actions[bot]

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[bot] avatar Sep 17 '22 00:09 github-actions[bot]

https://eips.ethereum.org/EIPS/eip-1193#events our current providers should be in compliance with this.

jdevcs avatar Nov 15 '22 18:11 jdevcs

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
        )}`
      );
    });

RaresGeo avatar Jan 10 '23 21:01 RaresGeo

Thank you for your attention. Let me add a little bit of details:

  1. this task was done only for the 4.x version of web3js
  2. 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',()=>{
    // ...
})

avkos avatar Jan 10 '23 23:01 avkos

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

RaresGeo avatar Jan 11 '23 13:01 RaresGeo

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.

avkos avatar Jan 11 '23 14:01 avkos