Client and server error data is inconsistent

[mattmess1221]

Environment

N/a

Reproduction

<script>
// serverError.data = { url: "/api/__api_party/api", statusCode: 400, statusMessage: "Bad Request", message: "Bad Request", stack: "<pre>...",  data: { message: "This is an error" }}
const { error: serverError } = useApiData("someerror")
// clientError.data = { message: "This is an error" }
const { error: clientError } = useApiData("someerror", {
  client: true
})
</script>

Describe the bug

When switching between client and server on the same endpoint, the error returned is different. When using a client endpoint, as expected, the error data is returned from the backend as is. Though when using a server endpoint, it returns the error data wrapped in another object. This can be confusing if you're not expecting it.

One option to solve this would be to inline the error manually inside the composable error handler.

catch (error) {
  if (!client && error instanceof FetchError && error.response) {
    const { response } = error
    response._data = response._data?.data
  }
  throw error
}

This would be a breaking change.

Additional context

I discovered this while tinkering with #38. As it may involve a breaking change, I figure I should open an issue for it first.

Logs

No response

[johannschopplich]

I see. Thanks for the report! I will take a look into your PR later. I wonder if we can transform the H3Error to an FetchError on server-side calls (process.server).

[mattmess1221]

I don't think it's actually related to SSR. It has to do with H3's (opinionated?) http error handling. It responds that way for every API endpoint. This is how it responds to a generic 404.

{
  "url": "/api/foobar",
  "statusCode": 404,
  "statusMessage": "Page not found: /api/foobar",
  "message": "Page not found: /api/foobar",
  "stack": ""
}

[johannschopplich]

Will be fixed by #44, right?

[mattmess1221]

Yes, will be fixed by that pr.

[johannschopplich]

Thought so. Just wanted to double-check. 🏁