Custom Node - Best way to return error

Questions
1

We are developing a node for our SaaS product (https://www.getplugged.io) in order to publish it for public usage. We want to be sure our design is aligned with the best practices of n8n.

The node makes mostly REST calls to the public service api. If the call is not sucessful we return in the api some HTTP status code different than 20x. It can be problems with validations, authorization, etc and we use either 40x, 30x or 50x status code depending on what happened. Additionally, we return a JSON object with information about the error that it should be shown to the consumer (n8n) in order to let the user know why it failed.

What’s the correct way to expose those errors in the node?

If we just use responseData = await this.helpers.request(options); The response is an error but the user cannot see our response data.

We changed the implementation to something like:

try {
		responseData = await this.helpers.request(options);
	} catch (e:any) {
		responseData.error = e.error;
		responseData.error.method = options.method;
		responseData.error.uri = options.uri;
		responseData.error.body = options.body;
	}

But in that case the user has to evaluate the response each time to see if there was an error or not, something not very intuitive.

What do you recommend?

1 Like
2

Hi @serquicia, welcome to the community :tada:

From the sounds of it you are already reading the response code and error body. Based on this information you could simply throw a new error with a user-friendly error message in your node code (could be as simple as throw new Error('Foo');). The message would then be rendered by the UI:
image

Throwing a more user-friendly error depending if certain conditions are met is similar to what existing nodes do.

3

I think I’ve run into that same problem. That is the request helper throws an error and doesn’t allow you to read the response data or headers.

Recently I had no option but to retrieve non-success status code responses. The solution (not accepted yet) was to update the httpRequest helper to allow validating all response codes as OK and allow the developer to make the decision on error or success. See here - 🐛 Handle Wise SCA requests by pemontto · Pull Request #2734 · n8n-io/n8n · GitHub

An excerpt from that PR:

:construction: 403/error responses

By default all of the request helpers treat non-success codes as errors. To get back the error response with headers I needed to add the Axios validateStatus option to the IHttpRequestOptions. In developing nodes I’ve sometimes wondered if I could get all responses and decide what constitutes a failure condition. Is this something I’ve missed that is already possible?

4

Perfect!

I finally did this:

try {
	responseData = await this.helpers.request(options);
} catch (e:any) {
	var error = new NodeApiError(this.getNode(), responseData, { message: e.error.message ? e.error.message : e.error });
	error.cause = options as any;
	throw error;
}

With this we got a message that means something to the user and in “Cause” we send everything from the request so the user can debug the problem.

1 Like
5

:+1:
You may want to strip any credentials or auth headers from the options object before returning it.