We're launching a new line-of-code based method of grouping errors. If you enable this grouping method in "App settings", we will find the line of code that was the source of the error and use it to split out errors that would otherwise be grouped together in AppSignal.

To access the feature, upgrade to the latest version of AppSignal's Node.js or Elixir integration.

Line-of-code based error grouping is especially useful for monitoring Node.js and Elixir applications, because in these languages errors of similar types might indicate different problems in your application.

The Problem We Fixed: Errors Hiding in Plain Sight

In our existing error grouping, errors are put in the same incident if they have the same type and occur in the same endpoint. This works great for some languages, but not so great in others.

In Node.js specifically, there are some error types that can indicate different issues in your code. TypeError is a prime example of this. It can contain entire classes of errors:

• an operand or argument passed to a function is incompatible with the type expected by that operator or function; or
• when attempting to modify a value that cannot be changed; or
• when attempting to use a value in an inappropriate way.

That covers a lot of ground! We got a lot of feedback from customers that use Node.js that our existing way of grouping could be much more specific. So we fixed that.

If you enable the new error grouping, we will figure out what line of code in your app was the source of the error. That will be used as a component to group on, which gives you much deeper insight into the various categories of errors in your app. The new error grouping will flag these as separate errors and, by default, alert you the first time a new error like that happens after a deployment.

New Error Grouping in Practice

Let's say we run a blog. A user can log in to the admin system, and we can create and load blog posts. We've nicely abstracted those concerns away into two services: blog and user. You can find them both here.

We end up calling these services from the same route.

app.get('/error', (req, res) => {

You can find the whole app file here.

Both of these services can raise an error with the same type. In the old situation, these errors would be grouped together:

In the new situation, it looks like this. The perpetrator is no longer hiding in plain sight, and you will know where to look for it.

We see two distinct errors here based on the line of code in your app where they originated. With the old, more course error grouping, the urgent error might be snowed under.

If you want to see the code for yourself check out this app in our test setups repo.

Why Group Errors This Way?

In languages like Ruby, by default and convention, people name their errors quite specifically. This is a great way of grouping errors. We've always grouped these by Action (what you'd call path in the Node.js stack) as well.

In Elixir, this is less common - "FunctionClauseError" and "KeyError" catch a lot of the errors out there.

In JavaScript, whether it's used in the front-end or in Node.js backend, TypeError catches a LOT of errors. Although the errors in AppSignal were grouped by route, that often wasn't what customers wanted.

We wanted to make the error tracking experience a level better for our Node.js and Elixir customers.

Mission Accomplished, Stroopwafels Earned

Now that errors are grouped more specifically, we've made tracking them a step better. As always, all features are included in all plans, and we're free for open source and 'for good' projects. If we helped make your work easier, that makes our day a bit sweeter.

If you are using or trying out AppSignal and want a bit of a sweeter day as well, just reach out and we'll send you some stroopwafels.