-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stricter Setup / Start API separation #66366
Comments
Pinging @elastic/kibana-platform (Team:Platform) |
a preliminary list of changes on the server side to understand the magnitude of refactoring:
|
I believe this one should still be in setup since it is used to expose a context provider registry to other plugins. |
We even want to move to |
We are going to start with logging a warning whenever lifecycle API is called outside of the current lifecycle timeframe #124039 |
From the very beginning Kibana platform uses a notion of lifecycles to separate runtime process into different stages:
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:
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:
start
phase.Child tasks:
The text was updated successfully, but these errors were encountered: