[Streams] Centralize error handling #207858
Conversation
dgieselaar
added
release_note:skip
| export const createServerRoute = createServerRouteFactory<StreamsRouteHandlerResources>(); | ||
| const createPlainStreamsServerRoute = createServerRouteFactory<StreamsRouteHandlerResources>(); | ||
|
|
||
| export const createServerRoute: CreateServerRouteFactory< |
There was a problem hiding this comment.
Not trying to make things more complicated, but this seems very useful in general - should we move this and StatusError into the helper package?
Not a blocker.
There was a problem hiding this comment.
Yeah, would like to see more use cases (not sure about subclassing etc) but will share with the devex wg
There was a problem hiding this comment.
The SLO plugin did something like this a bit back, I guess we're still waiting for the third use case to generalize over.
There was a problem hiding this comment.
Hmm I just had a look, the way it's implemented in the SLO plugin is that it loses all type fidelity
| @@ -48,11 +47,6 @@ export const retryTransientEsErrors = async <T>( | |||
| await setTimeout(retryDelaySec * 1000); | |||
| return retryTransientEsErrors(esCall, { logger, attempt: retryCount }); | |||
| } | |||
|
|
|||
| if (e.meta?.body?.error?.type === 'security_exception') { | |||
There was a problem hiding this comment.
I'm just propagating the ES error here
x-pack/solutions/observability/plugins/streams/server/lib/streams/helpers/retry.ts
Show resolved
Hide resolved
x-pack/solutions/observability/plugins/streams/server/lib/streams/client.ts
Show resolved
Hide resolved
x-pack/solutions/observability/plugins/streams/server/routes/streams/ingest/route.ts
Show resolved
Hide resolved
💚 Build Succeeded
Metrics [docs]
cc @dgieselaar |
| constructor(error: errors.ResponseError) { | ||
| super( | ||
| error.body?.error?.reason || | ||
| error.body?.error?.caused_by?.reason || | ||
| error.message || | ||
| 'Unknown error' | ||
| 'Unknown error', | ||
| 400 |
There was a problem hiding this comment.
Seems like this is not necessarily a 400, should we just forward what's coming from Elasticsearch here instead?
Centralizes the error handling by: