Add plugin status API

[joshdover]

Summary

Related to #41983

Implements the core.status.set, core.status.plugins$, and core.status.derivedStatus$ APIs as specified in RFC-0010.

I did not write any e2e tests in this PR as I thought it would be easier to write them directly against the migrated status HTTP API that I am working on in parallel.

To Do:

• Add complete example docs to StatusServiceSetup that explains how plugin statuses work, how they are inherited, and how to customize them.

Dev Docs

Kibana Platform plugins may now read the status of their dependencies, their plugin's default status, and manually override that status as reported to the end user and on the /api/status endpoint.

class MyPlugin {
  setup(core) {
    // Override default behavior and only elevate severity when elasticsearch is not available
    core.status.set(
      core.status.core$.pipe(core => core.elasticsearch);
    );
  }
}

Checklist

Delete any items that are not applicable to this PR.

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[joshdover]

This highlights a current problem with this Observable-based architecture: a single update to one plugin's status may result in many overall updates as it propagates through the dependency tree.

I plan to experiment more tomorrow with RxJS's various schedulers and debouncing utilities, but I'm not sure yet there is a great solution to this. Even if there is, we still would need to provide guidance or utilities so that plugin authors can also avoid this same issue in their custom status implementations.

[mshustov]

https://www.learnrxjs.io/learn-rxjs/operators/filtering/debouncetime after combineLatest? Can it be backed in the core in order not to enforce plugins to wrap it manually?

[pgayvallet]

+1 for debounce effect of some kind to the overall$ and plugins$ observables. We probably want to keep the derivedStatus$ exposed to plugins 'fresh' to avoid delay in status recomputation though?

[joshdover]

My goal was to avoid any time-based approach in order to make the behavior very consistent for synchronous Observable sources. I was able to get this to work using debounce with a variable number of microtasks based on the number of known observables. Seems to be working correctly! Now the observables should only emit once per macro-task.

[joshdover]

I decided to just go with a time-based apporoach after all. Microtasks seemed like too much magic and very fragile to break. It's also easy to write a test which ends up changing the microtasks queue itself, leading to strange results in tests.

We probably want to keep the derivedStatus$ exposed to plugins 'fresh' to avoid delay in status recomputation though?

+1 to that. I am only going to debounce the overall$ and plugins$ observables

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[joshdover]

Changed the summary output for when only a single service is unavailable to be more consistent with the case where more than one is unavailable.

[mshustov]

does it mean that all this.pluginsStatus API consumers have to implement debouncing manually?

[joshdover]

Now that debouncing is configured on the Observable used to wrap a plugin's dependencies (the core.status.dependencies$ Observable), I don't believe this will be a problem that "fans out" to consumers, so manual debouncing should be unnecessary.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 476fb75

Build metrics

oss distributable file count

id	value	diff	baseline
total	27306	+1	27305

distributable file count

id	value	diff	baseline
total	45456	+1	45455

History

• 💔 Build #71435 failed 8bee167
• 💚 Build #70722 succeeded 2aaaf8c
• 💚 Build #70415 succeeded 3ea7db2
• 💔 Build #70407 failed a0a091e
• 💔 Build #70182 failed 1440cc5

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream