Recoverable Error Handling

[rowanmanning]

I wanted to do a bit of a brain dump about recoverable error handling so that if anyone has thoughts they can contribute while I'm away (and also I will forget everything between now and July if I don't write it down).

I think we need to add in a package for handling recoverable errors (aka silenced errors) where the app can continue to render a page even if an error occurs. E.g. if an API fails then part of the page is not rendered but the end user still gets a 200 status code and a partially complete page.

Currently our logs for these kinds of errors are just as inconsistent as our standard error logging. Technically engineers on our teams can now produce quite detailed logs like this:

import serializeError from '@dotcom-reliability-kit/serialize-error';
import serializeRequest from '@dotcom-reliability-kit/serialize-request';

app.use('/example', (request, response) => {
    try {
        // Something which throws an error
    } catch(error) {
        logger.warn({
            event: 'RECOVERABLE_ERROR',
            error: serializeError(error),
            request: serializeRequest(request)
        });
    }
    response.render('example');
});

However this is quite a lot of boilerplate, and could easily lead to inconsistency (e.g. if people decide to change event on a per-route basis or if they forget to include the request details in some places). It would also be easy to mix up warn and error for these cases resulting in more inconsistency.

I think maybe we should provide something like this in order to codify the format and make sure that recoverable errors are logged in the same way as unrecoverable errors:

import logRecoverableError from '@dotcom-reliability-kit/log-recoverable-error';

app.use('/example', (request, response) => {
    try {
        // Something which throws an error
    } catch(error) {
        logRecoverableError({error, request});
    }
    response.render('example');
});

In this example, request could be an optional parameter so that we also cater for non-HTTP contexts. I think this will result in more consistency going forward and the method name is really explicit and it's clear what it's for.

[JSRedondo]

I llike the idea of the request as optional parameter