Getting error URLs

[juriejan]

I'm currently sending the URL generated for a specific error by my error tracker in the error response to my front-end application. I do this so that I can easily refer to the error that took place on my API from errors that are logged for my front-end application.

Is there a way to get the URL of the error on the NewRelic platform using this library?

Is there perhaps a simpler way to achieve this with the NewRelic platform?

[othiym23]

If your main concern is putting all the errors encountered by your application in one place, you might want to play with the browser monitoring support we just added to New Relic for Node. Alongside timings, it also has good browser error tracing. It's a little tricky to use with API applications, because the API call just returns a chunk of JavaScript to be embedded in the page, but with a little poking, you should be able to get it to work. Is that what you're looking for?

[juriejan]

I'm specifically interested in being able to go directly to the back-end error that caused a failed AJAX request on the front-end, which is also requested by my browser error tracker.

I'll definitely be checking out the browser monitoring support, but I need some way to point to the error on the back-end that caused the error on the front-end, if there was any back-end error at all.

[othiym23]

Ah! I didn't really understand the question, but think I have a better handle on what you're talking about now. I think there are probably two pieces to what you're asking for, and unfortunately I don't think either is available out of the box:

1. The error tracer is pretty much a standalone piece of the agent. As written, it's not meant to be hooked into from your application, which makes it tough to get at all the errors that might impinge on a request.
2. The URLs to error traces in the New Relic UI are generated on the server side, and that information isn't passed back to New Relic for Node (only configuration information is sent to the module), so there's not a really good way to generate a URL to pass down to the client.

So it does seem to me that it may be easier just to push all the error information to New Relic than try to put that information into your client. Sorry if this is a bummer, but this is one of those features that's easy to request but surprisingly hard to add.

[juriejan]

I thought it might be quite tricky. Airbrake currently allows me to get a URL to the error that was created.

I'm quite interested in how other people would usually handle this type of scenario. How would you suggest a solid synchronization between back and front-end errors?

[othiym23]

That's a good question. I feel that typical users of a site or app don't really care about error information they can't act on. It should be enough (in most cases) just to let them know that something bad happened, while at the same time making sure the error gets registered so that developers have enough context to fix the problem later.

Even when a site is in dev mode, if there's a failure on the back end, I generally want that failure to stop things immediately, and not allow things to continue such that the front end might fail as well.

This isn't to say that what you're asking for is unreasonable. It's just not what I personally would do, nor is it something New Relic was designed to support. To get what you want, I'd probably pull error storage, serialization, and display into the app itself. That gives you full control, and allows you to decide exactly how to connect front and back end errors. You could also look at manually mashing up Airbrake's back-end error tracking with New Relic's browser error monitoring, but that actually sounds like more work to me. Sorry I don't have an out of the box solution for you!

[juriejan]

Yeah I guess if API errors are handled on their own the problem would be solved never the less. Just seemed useful to me to get a reference to the error that occurred on the back-end that effected the front end. Thanks for the chat!

[txase]

I'm closing this issue as there's nothing actionable for us to do at this point in the node.js agent.