fix: Throw better error message if version parsing fails

[justinkambic]

The Agent sends a request to Kibana during push operations to check its version number. Unfortunately, the API endpoint responsible for returning this data will always return a 2XX error code, even if credentials are invalid, for reasons, essentially because this endpoint acts as a heartbeat for Kibana in certain cases.

Better solution

We can get around this issue by calling /api/stats instead of /api/status. This endpoint returns the Kibana version and will throw a 401 in the event of a garbage API key, thus solving both problems.

---

Note: the rest of the info in the description is kept for context, but we will employ the solution explained above.

Example

# API key
abc123

# Command with incorrect key
env SYNTHETICS_API_KEY=abc12 npm run push

Explanation

Because we don't receive a 401, the Agent's internal HTTP error handling will not display any error, per its design. Unfortunately, because this issue falls through to the calling code, when we do receive an error, it is very unhelpful from a UX perspective. At this point, the user is trying to push their monitors. While waiting with their fingers crossed, hoping to see a success message, receiving a log like the example output below is confusing, disheartening, and a bad experience.

➜ npm run push

> [email protected] push
> npx @elastic/synthetics push

TypeError: Cannot read properties of undefined (reading 'number')
    at getVersion (~/lugia/node_modules/@elastic/synthetics/src/push/kibana_api.ts:138:23)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at Command.<anonymous> (~/lugia/node_modules/@elastic/synthetics/src/cli.ts:212:31)

My proposal is that the Agent should diagnose this novel error and throw a custom message in this case. The copy is by no means final and I am open to suggestions.

I'm aware that this is essentially fixing the problem by introducing tech debt. A longer term alternative fix to this approach would be to have Kibana provide a dedicated version API endpoint that could handle HTTP errors in the conventional way, but having spoken to the team, at this point it seems unlikely we will see this change in the short term. As the "fix" here has a really small footprint and is encapsulated to just this function, it seems acceptable to me, but I'm open to alternative solutions as well.

[vigneshshanmugam]

Code LGTM, can you add a test for the same?