[Telemetry] Possible race condition in stack_stats search reporting

[thesmallestduck]

I believe the metrics collection code found here can result in a possible race condition:

kibana/src/plugins/data/server/search/collectors/usage.ts

Lines 30 to 60 in 170a295

	try {
	const response = await repository.get<Usage>(SAVED_OBJECT_ID, SAVED_OBJECT_ID);
	attributes = response.attributes;
	} catch (e) {
	doesSavedObjectExist = false;
	attributes = {
	successCount: 0,
	errorCount: 0,
	averageDuration: 0,
	};
	}
	attributes[eventType]++;
	// Only track the average duration for successful requests
	if (eventType === 'successCount') {
	attributes.averageDuration =
	((duration ?? 0) + (attributes.averageDuration ?? 0)) / (attributes.successCount ?? 1);
	}
	try {
	if (doesSavedObjectExist) {
	await repository.update(SAVED_OBJECT_ID, SAVED_OBJECT_ID, attributes);
	} else {
	await repository.create(SAVED_OBJECT_ID, attributes, { id: SAVED_OBJECT_ID });
	}
	} catch (e) {
	// Version conflict error, swallow
	}
	};
	};

This could result in telemetry data that is inaccurate. I believe moving the increment and average calculation to thread safe implementations should fix it.

[elasticmachine]

Pinging @elastic/kibana-telemetry (Team:KibanaTelemetry)

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[afharo]

Good call @thesmallestduck! SOs API now provides an improved incrementCounter API. Maybe this is a good fit.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)