search

OpenFn / kit

The bits & pieces that make OpenFn work. (diagrammer, cli, compiler, runtime, runtime manager, logger, etc.)
8 stars 12 forks source link

Error objects don't log well #720

Open josephjclark opened 1 week ago

josephjclark commented 1 week ago

A few adaptors have a pattern where they create an Error object and throw it.

image

This isn't itself unreasonable!

But when serializing that error for the console or the final state, we lose all the detail.

If I console.log this error, I do see some of the properties: image

Here you can see my custom status code.

The stack trace right now is not useful - although will be once we handle source mapping

The thing we report in the CLI isn't so good:

image

And the thing we write to state is useless:

image

No surprises here, it's just getting a better understanding of how different errors are reported out of the runtime

josephjclark commented 1 week ago

Probably the code that generates that error object on state should serialize all the keys of the error object into JSON.

And the Runtime log at the end, which says check state for details, should pretty-print the keys nicely too

josephjclark commented 5 days ago

Maybe related? Posting here

In okd, using http helpers without much wrapping, I see this in my logs:

image

Ok, it reported a 404, but there's more data in the error response.

State doesn't show anything useful:

{
  "data": {},
  "errors": {
    "job-1": {
      "type": "AdaptorError",
      "stepId": "job-1",
      "message": "GET to https://sandbox.getodk.cloud/v1/projects/69 returned 404: Not Found",
      "error": {
        "source": "runtime",
        "type": "AdaptorError",
        "name": "AdaptorError",
        "severity": "fail",
        "message": "GET to https://sandbox.getodk.cloud/v1/projects/69 returned 404: Not Found"
      }
    }
  }
}

But the actual Error object that was reported is super rich! This should serialize better!

image