MaxListeners Error

From @nax: "sometimes we’re getting errors like:

MaxListenersExceededWarning: Possible EventTarget memory leak detected. 11 abort listeners added to [AbortSignal]. Use events.setMaxListeners() to increase limit

In our logs, seems to happen periodically for a minute or so. I searched the forum and seems like maybe it’s something from the ceramic server side, not sure."

Here are related issues i’ve found:

fyi @mohsin you responded to both of this previously, so you might have context

@ukstv tagging you in

Hey @nax - we have a PR up that should fix this, we’re waiting on Protocol Labs to merge it feat: Add `clear` method for a composite signal by ukstv · Pull Request #24 · jacobheun/any-signal · GitHub

Thanks for reporting and your patience

@nax Max, this should be fixed as of yesterday! feat: Add `clear` method for a composite signal by ukstv · Pull Request #24 · jacobheun/any-signal · GitHub

@nax The root cause of that is ipfs-http-client does DAG traversal on the client side, and on every traversal step plus one event listener gets added to one long-lived AbortSignal.

Say, if you do ipfs.dag.get(cid, '/some/long/path/like/for/anchoring/root'), every element of the /some/long/path/... results in adding an event listener. After a certain number of listeners, Node.js starts complaining.

To be clear, we do not expect the issue to affect Ceramic node production in any significant way. Consider it an annoyance.

The path is to (1) provide a capability to remove the listeners, which is done in the PR mentioned above by @avi , (2) use the removal capability in js-ipfs-utils package which does the actual work. And, the second part is not quite fun, as the package has been neglected for a while (not by Ceramic folks; it is an internal dependency of our internal dependency).

Ok thanks! And thanks for the explanation. I had noticed it was a warning but wasn’t sure if it was causing any issues.