[Security Solution][Endpoint] Better error handling for ES errors

[paul-tavares]

Summary

• Improve error handling of errors, specifically those thrown by ES/SO clients
  • Logic in wrapErrorIfNeeded() will now check to see if the error being wrapped is from ES and if so, it will attempt to generate a better error message as well as capture additional debug data

[infra-vault-gh-plugin-prod]

Pinging @elastic/security-defend-workflows (Team:Defend Workflows)

[szwarckonrad]

I’ve left a few comments, but they don’t seem to be in the way. Please decide if they are worth pursuing.

[szwarckonrad]

AI generated:

This drops the structured logger path for errors. When an Error is passed to logger.error, Kibana's BaseLogger.createLogRecord builds a LogRecord with error: <Error> alongside message — ECS appenders use that to populate error.type, error.message, error.stack_trace, etc. Stringifying first collapses everything into message, and any consumer indexing on error.* (Filebeat → ES, etc.) silently loses those fields.

Could we keep the Error and put the new debug payload in LogMeta instead?

[szwarckonrad]

I believe we could go with something like

export interface EndpointErrorDebug {
  es_request?: {
    method?: string;
    path?: string;
    querystring?: unknown;
    body?: unknown;
  };
  es_response?: { body?: unknown };
}

export class EndpointError<MetaType = unknown> extends Error {
  public debug?: EndpointErrorDebug;
  // ...
}

[paul-tavares]

EndpointError is generic and also used by the UI, so I rather keep debug property set at any. Although with this change was triggered by the lack of detail while investigating a recent issue that originated from a ES error, the debug property is really to capture anything else that one might like to include when an error of this type if thrown.

[szwarckonrad]

Would it be worth adding a small wrap_errors.test.ts alongside this?

[szwarckonrad]

Instead of typin we could probably go with

if (error instanceof errors.ResponseError) {
  const { params } = error.meta.meta.request;
  debug = {
    es_request: {
      method: params.method,
      ...

[paul-tavares]

That will not work. Here I'm checking that the Error is one emitted by the Elastic search client (the base Error class) and that Error definition does not have a meta thus why I defined the type above. Tehre are a few errors that have the meta, so defining the type here allows us to capture data for all of them - including any new one that might be added in the future.

see node_modules/@elastic/elasticsearch/node_modules/@elastic/transport/lib/errors.d.ts to view the types defined for ES client errors

[kibanamachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 3ea526a

Failed CI Steps

• FTR Configs #12
• FTR Configs #141
• FTR Configs #149
• FTR Configs #162
• FTR Configs #179

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id	before	after	diff
securitySolution	105	106	+1

ESLint disabled line counts

id	before	after	diff
securitySolution	754	756	+2

Total ESLint disabled count

id	before	after	diff
securitySolution	859	862	+3

History

• 💛 Build #438211 was flaky 4021140
• 💛 Build #437498 was flaky a1cf606
• 💛 Build #436641 was flaky 1d0c5ab
• 💚 Build #435994 succeeded 9bae854

cc @paul-tavares

[tomsonpl]

LGTM 👍

[kibanamachine]

Starting backport for target branches: 9.4

https://github.com/elastic/kibana/actions/runs/25434301543

[kibanamachine]

💚 All backports created successfully

Status	Branch	Result
✅	9.4

Note: Successful backport PRs will be merged automatically after passing CI.

Questions ?

Please refer to the Backport tool documentation