analytics-node might cause an unhandledRejection

[yigaldviri]

Hi there,

Im trying to use this package to report events to Segment and as a consumer I'm trying to protect my server from errors. My code looks like this:

track = promisify(analytics.track.bind(analytics));

async report (userId: string, eventType: SegmentEvent, properties) {
    try {
      await track({
        userId,
        event: eventType,
        properties: addLinkToProperties(eventType, properties),
      });
    }
    catch (e) {
      log.warn('Couldn\'t report to segment about event', { eventType, properties, e });
    }
  }

I had a look at the package's code and I think that In some cases the package can cause an unhandledRejection error. For examplee, in case of a downtime on Segment servers.

I simulated it by changing the code and throwing an error inside the then clause of the flush function:

Tested it an indeed I got [ERROR] - unhandledRejection: Error: test an error

This kind of error might result in a server crush and using try/catch wont help either so am I missing here something? Is there a way to avoid that error? Or maybe my case can't really happen in reality?

[Eivar Montenegro]

I am trying to think of a use case for this other than the server being down or something else really bad, in which case makes sense to me that the app just fails; anyhow, the behavior that you describe is normal with promises:

Processing continues to the next link of the chain even when a .then() lacks a callback function that returns a Promise object. Therefore, a chain can safely omit every rejection callback function until the final .catch()

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise

[Shane L. Duvall]

Please re-open if more discussion is needed. Thank you

[Deleted user]

What is the solution here? Apps can have intermittent network disruptions, and a fatal unhandled promise rejection is a poor user experience. @emont01

[Gio]

Please re-open if more discussion is needed. Thank you

As requested by @nd4p90x ... looks like more discussion is needed. Could we re-open?

[Edson Amaya]

Hi @GCAndrew , @supermacro , @yigaldviri , I found a solution for this issue. You can handle the error with the next code:

The node process global has an unhandledRejection event for unhandled promise rejection.

[Deleted user]

@edsonjab it works but as said in #326,

Listening for uncaught exception events isn’t an ideal error handling pattern.

It is very user-unfriendly to require that the library's exceptions be handled inside the unhandledRejection handler.

[Edmundo Santos]

Just hit this and it crashed subsequent unrelated Lambda requests, this is definitely a poor experience and using .on('unhandledRejection') is not an acceptable solution, just return a regular Promise in the track event instead of skipping it.

[Gio]

Is this repo accepting PRs to address this issue? Either myself or a colleague are happy to submit a PR

[Edson Amaya]

Hi @supermacro, yes please, you can make a PR and we will check your solution.

[Gio]

Ok we've added this as an item on our backlog, can't promise an ETA but good to know that we can submit a PR when we get some time!

[Gio]

My colleague Tam has had his PR merged, so that solves the issue for us. Not sure if others here are looking for other fixes but our team is happy with this. Much appreciated 🙌

[yigaldviri]

When are you planning on publishing the updated package to npm?

[Shane L. Duvall]

Release 6.1.0 will resolve this issue, thank you.