elastic/kibana

[Telemetry] Better error handling at the `telemetry_plugin_collector`

Open

#122,634 opened on Jan 11, 2022

View on GitHub
 (4 comments) (1 reaction) (0 assignees)TypeScript (8,021 forks)batch import
Feature:TelemetryTeam:Coregood first issueimpact:lowloe:small

Repository metrics

Stars
 (19,065 stars)
PR merge metrics
 (Avg merge 1d 16h) (999 merged PRs in 30d)

Description

In the telemetry_plugin_collector we are swallowing any errors thrown by getTelemetrySavedObject: https://github.com/elastic/kibana/blob/c2641bd8cc875dd50c63a40fbaf3054780cd570b/src/plugins/telemetry/server/collectors/telemetry_plugin/telemetry_plugin_collector.ts#L45-L52

I don't think that we should do this as we might report different data depending on whether there's an ES connection issue or not (because when there's no savedObject information we rely on the kibana.yml config values).

IMO, we should either let the collector fail or populate the related fields only when getTelemetrySavedObject succeeds.

Contributor guide

Research direction
Examine the telemetry plugin collector code, specifically the try catch block swallowing errors from getTelemetrySavedObject. Determine if failing on error or conditionally populating fields is safer. Consider the impact on data reporting when ES connection fails.
Tech stack
typescript
Domain
backend
Issue type
Bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
2
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
Git
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70