0.1.12 • Published 3 years ago

@jetti/jetti.problem v0.1.12

Weekly downloads
1,570
License
MIT
Repository
github
Last release
3 years ago

Library for propagating 7807 errors, based on api-problem (https://github.com/ahmadnassri/node-api-problem). You'll need to import into the repository you want to trigger the errors form. This should replace all throw new Error() calls with the following code:

    import { ApiProblem } from '@jetti/jetti.problem';
    throw new ApiProblem({
        code: 'api.channels.process_sale.missing',
        details: {
            externalId,
        },
    });

For errors related to Sequelize models:

    import { InstanceProblem } from '@jetti/jetti.problem';
    const instanceError = new InstanceProblem({
        instance,
        action: 'export',
        // or module.filename,
        // Optional
        content: 'empty,'
        // Optional
        details: {
            externalId: '1234',
        },
    });

For errors related to integrations:

    import { IntegrationProblem } from '@jetti/jetti.problem';
    const integrationError = new IntegrationProblem({
        integration: 'wooCommerce',
        resource: 'orders',
        action: 'import',
        context: 'no_attributes',
        details: {
            externalId: '1234',
        },
    });

Although not a requirement, you can create a Contentful entry under the error content type, with a corresponding code. This will then merge the title into the error message. The details array should contain any useful details about the error, in alignment with the 7807 spec.

You'll need to add an .env file for the build process:

CONTENTFUL_SPACE={{space}}
CONTENTFUL_TOKEN={{token}}

Decorators

For convenience, it's also possible to wrap class methods to capture any unhandled exceptions. This will coerce any errors into the problem 7807 standard.

    class Postmen {
        // Or CatchApi()
        @CatchIntegration({ resource: 'rates', ...options })
        rates() {
            throw new Error('Something unexpected');
        }
    }

Often, integrations will pass back errors in different formats. For example, have an errors array, or maybe a meta object that lists the errors. It's useful to get these varying error messages and consolidate down to a common format. For a jetti.problem, this will be detailed in the details object. To handle this conversion, the calling / catcher of the problem should pass a parser function that takes a given request response and allows mapping map to a common format.

const throwMe = {
    variant: {
        message: 'not found!',
    },
};

const parser = ({ response: toPrase }) => ({
    messages: Object.entries(toPrase).reduce((obj, [code, { message }]) => ({
        [code]: [message],
        ...obj,
    }), {}),
});

@IntegrationCatch({ parser })

This will take a request object, map the data and pass back in a format below. It should return an array of messages, in the format below.

{
	"type": "https://problems.jetti.io/details#integrations.postmen.rates.rates",
	"title": "integrations.postmen.rates.rates",
	"status": 418,
	"details": {
		"message": "Response code 418 (I'm a Teapot)",
		"response": {
			"variant": {
				"message": "not found!"
			}
		},
		"messages": {
			"variant": ["not found!"]
		},
		"integration": "postmen",
		"resource": "rates",
		"context": "rates"
	}
}

If there is no "code" and the integration just returns an array of messages, you should use "all",

    ...
    "messages": {
        "all": ["not found!"]
    },
    ...
0.1.12

3 years ago

0.1.11

3 years ago

0.1.10

3 years ago

0.1.9

3 years ago

0.1.8

3 years ago

0.1.7

3 years ago

0.1.6

3 years ago

0.1.5

3 years ago

0.1.4

3 years ago

0.1.3

3 years ago

0.1.2

3 years ago

0.1.1

3 years ago

0.0.12

3 years ago

0.0.10

3 years ago

0.0.9

3 years ago

0.0.8

3 years ago

0.0.7

3 years ago

0.0.6

3 years ago

0.0.5

3 years ago

0.0.4

3 years ago