From the very beginning Kibana platform uses a notion of lifecycles to separate runtime process into different stages:

• setup - the preparatory stage. It should be used to declare cross-plugin dependencies and dependencies on the platform functionality. Kibana remains at this stage for a limited amount of time. In the future, this amount of time may be reduced to one tick.
• start - the runtime stage. Meant to be used to perform the Kibana functionality. It's a long-running stage. Kibana is in this state most of the time while it's running.
• stop - the teardown stage. It might be used to clean up resources and stop ongoing operations.

However, all the stages exist merely as a convention. This has led to the fact that plugins (and the platform itself) mix functionality up and provide runtime API from setup phase. As a result, when the platform decided to refactor public contracts we have realized it cannot be done due to the number of existing external dependencies.
Not the full list of the blocked tasks:

• Move elasticsearch client creation/access API from core setup to start contract #55397

To prevent problems in the future, we are going to reinforce the separation of the lifecycle stages. Otherwise, we have to add defensive checks in the code that API can be called, which is an error-prone approach. By default API exposed from start lifecycle stage unless it's crucial to move it to the setup stage

Suggestions:

• to move platform API meant to be used in runtime to the start phase.
• identify plugins that can be affected by this change and create issues for code owners to refactor the public API.
• add a tracking mechanism to monitor all the cases when API is called from a not-relevant stage.
• fix all the problem places.
• enforce a hard separation for API. Invoking API from another stage will throw an exception.

Child tasks:

• Remove UISettings accessors from core setup contract #55396