web3 / web3.js

Collection of comprehensive TypeScript libraries for Interaction with the Ethereum JSON RPC API and utility functions.
https://web3js.org/
Other
19.3k stars 4.95k forks source link

The event handler for a subscribed event is invoked multiple times and the amount of invocations seems to be related to the amount of event subscriptions in the client code. #4010

Closed uwieske closed 3 years ago

uwieske commented 3 years ago

Hi, I am experiencing the same underlying problem which had been reported in #2485. That is, I have many event types defined in my contract. When my client application (angular app) subscribes to each event type (through Web3js) and only one particular event has been emitted in my contract, then I see for this particular event multiple invocations (event handler) that have been made. The weird thing about this, the amount of handler invocations coincides with the number of event subscriptions over all event types in my client code.

Question to developers: It seems like this problem has not really been addresses/discussed and possibly resolved. Is there already a documented analysis for this issue? If this is an issue in web3js, in which release of Web3js will the problem be resolved?

Situation:

My contract declares 3 event types, i.e. event Event1(), event Event2(), event Event3(). There is a contract function (function fun1()) which emits one event, for instance Event1(). My client app uses Web3js and subscribes on all 3 event types. When the fun1() emits Event1(), the associated event handler in my client app is supposed to be invoked only once. But, It is invoked 3 times. The weird thing is that there is a relation between the amount of event subscriptions in the client code. So, in this illustration I had 3 subscription, because I there were 3 different event types declared in the contract. Apparently, -in my specific situation- the amount of invocations of my event handler has nothing to do with block range. An observation which I have been reading about in the documentation of Web3js and Stackoverflow.

If my client subscribes to one particular event type (Event1), then when the contract fires I expect to see only one invocation of the event handler declared in my client code.

In my contract:

contract MyContract {

  event Event1();
  event Event2();
  event Event3();

  // ... here different functions and constructor

  function fun1() public payable {
    //... some state transformational statements

    // emit event
    emit Event1();
  }
}

Client code (angular app):

// .. get contract instance of MyContract
myContract = this.getMyContractInstance();

// subscribe to receive Event1 events
const event1 = myContract.events.Event1();
event1.on('data', (event) => {
  console.log('Event 1: ', event);
});

// subscribe to receive Event2 events
const event2 = myContract.events.Event2();
event2.on('data', (event) => {
  console.log('Event 2: ', event);
});

// subscribe to receive Event3 events
const event3 = myContract.events.Event3();
event3.on('data', (event) => {
  console.log('Event 3: ', event);
});

Actual behavior

Output in console when the smart contract fires event Event1: Event 1: {...} Event 1: {...} Event 1: {...}

Take notice of the repeating 'Event 1' above! If I would declare an extra event (Event4) in my contract and subsequently let the app subscribe to this newly event type, then I would see 4 occurrences of the same message in my console!

Expected behavior

I expect only one message (one invocation): Event 1: {...}

Logs

I refer to the output of the illustration above.

Environment

Versions used of: npm 6.14.11, Node 14.15.5, web3.js 1.3.4. and 1.3.5 (problem in both versions), OS Mac OSX, device MacBookPro

spacesailor24 commented 3 years ago

Thank you very much for the detailed report! Our team doesn't have the availability to work on this just yet, as we're focusing on rewriting the library (v4.x), so I can't give you an estimate on when this issue would be resolved

That said, I will verify that this issue does not persist in the rewrite

Sixtisam commented 3 years ago

Still there in 1.3.6 1+

xenide commented 3 years ago

Same, facing the same problem in 1.3.6

github-actions[bot] commented 3 years ago

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.

0x7An commented 3 years ago

@uwieske this problem was driving me crazy, thanks for the issue.

I had to store the transaction hash, and check if it exists before doing any logic after the events.