@sevaru Could you review please?

Thank you for your pull request and the effort you've put into it!

Upon review, we've noticed behavior differences with the native Sentry client, particularly regarding the cause field and extra error data handling.

To align with our goal of keeping micro-sentry code and request data minimal, your suggestion to extend a class and override the prepare method is the best approach for now.

Highlights:

• Cause Field: We follow the native Sentry client's approach to unwrap errors, using plugins like LinkedErrors.

{
  "exception": {
    "values": [
      {
        "type": "Error",
        "value": "cause exception text"
        // ...
      },
      {
        "type": "Error",
        "value": "parent error"
        // ...
      }
    ]
  }
  // ...
}

• Extra Error Data: Instead of attaching additional fields to extras, we use contexts, as per the ExtraErrorData plugin.

{
  "contexts": {
    // ...
    "Error": { "myField": "myField" }
  }
}

Moving Forward:

We're considering adding more flexible plugin capabilities in the future, similar to your contribution.

Let us know if you interested in trying out the new plugin system once it's available!