chore(cause): added error cause

[dreamsparkx]

related: krakenjs/confit#93

[jonathansamines]

IIRC, ultimately only this "string" keys actually result in meaningful work that can cause external failures. On a typical configuration resolved through shorstop, you'll have something like:

{
  "complex": {
    "key": "protocol-a:first-value",
    "other": [
       { "child": "protocol-b:second-value" }
    ]
  }
}

In the example above, ultimately only leaf nodes (e.g strings) are actually processed through shorstop handlers, and therefore yield external work. Other intermediate nodes are either only traversed (e.g objects or arrays) or ignored (e.g other primitives).

So this is probably the most meaningful piece of code we can instrument with an additional error in the causal chain. As it contains key information that could help us identify the underlying issue:

• What "protocol" we were processing when the failure happened?
• What "value" we were processing when the failure happened?
• What "handler" we were processing when the failure happened? (A note here, handlers are not typically named, but we can always try to guess by using the function name and fallback to something like "unknown" in case of anonymous functions)

For the sample configuration above, I would expect errors to contain all of that information:

Error occurred while resolving "protocol-a" protocol with value "first-value" at "handlerNameOrUnknown" handler.
 ...
 cause ...

Without this information, this intermediate error in the causal chain is not really useful, and will only be additional noise in our logs.

[dreamsparkx]

@jonathansamines new information added.

[jonathansamines]

After closely looking at this, I think right now, we are only dealing with synchronous handlers function handler(input), but we actually need to do something similar for asynchronous handlers, which have a different signature function handler(input, cb).

I think we'll need to do wrap L201 with a callback that simply wraps handler and decorates errors with the additional information before propagating. Something like:

- return handler
+return function handl(...args) {
+   const next = args[args.length - 1];
+
+   function cb(err, ...ar) {
+        return next(new Error('error with more info', { cause: err }), ...ar);
+   }
+
+    args[args.length - 1] = cb;
+
+    return handler(...args);
+}

The changes should look roughly like that, but I'd test and update/add new tests if necessary to ensure those changes behave as intended.