Validate plugins in /plugins API and skip invalid ones with warnings#55673
Validate plugins in /plugins API and skip invalid ones with warnings#55673pierrejeambrun merged 9 commits intoapache:mainfrom
Conversation
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Same comment as Pierre, it would be nice to add the tests. Thanks!
I have one small question for logging part.
After Switch all airflow logging to structlog #52651, do we need to switch to structlog for Core API as well?
cc @ashb
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
@jason810496 We can switch things over to |
ashb
left a comment
There was a problem hiding this comment.
Handling this at the API layer is not really the right place, it should be handled and validated earlier on when plugins are first loaded I think
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Just to answer @ashb concerns, we have multiple layers of validation.
Basically the plugin manager will 'load' (just import) plugins. There we allow almost 'any' type of dict object, because it's how it was done in AF2 to allow custom plugin structures.
We just do some very basic validation there, and plugins are considered 'loaded', only really hurtful mistakes that could crash the API server or cause bad behavior are ignored with an error message there.
Then for the API to actually be able to return those responses it has to be valid in regards to API layer pydantic validation. (or the route will crash). There we allow 'extra' keys similarly to AF2, but for existing keys / enums, they have to comply. If they do not match the serializer validation, they will be ignored from the response. (what we try to implement there, instead of erroring the plugin endpoint)
I didn't want to bring 'pydantic' API level validation to the plugin manager because it would introduce coupling from the plugin manager over some 'api layer' level validator, which didn't sound good at the time. I would like to achieve something similar at some point. Basically don't load and ignore anything that is not correct directly at plugin manager load time but:
- That could be considered breaking, plugin manager will stop loading stuff and other components (not the API) could still rely on those 'loadable plugins' but not serializable ones.
- I didn't find yet time and a good approach to achieve that (without the coupling mentioned above etc...)
So I think we should, remove plugins that the API cannot serialize, and have a count 'in sync' with that. So API client (UI basically), will just see valid plugins from the API standpoint. The PluginManager is more tolerant, and will try load more things as it used too in AF2.
airflow-core/src/airflow/api_fastapi/core_api/routes/public/plugins.py
Outdated
Show resolved
Hide resolved
airflow-core/tests/unit/api_fastapi/core_api/routes/public/test_plugins.py
Show resolved
Hide resolved
|
Thanks for the feedback @pierrejeambrun , I’ve updated the implementation to:
|
|
CI is failing, I'll rebase the PR to trigger it again. |
Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com>
208f740 to
2ad2327
Compare
|
Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions. |
|
Adding to 3.1 milestone. This feels like a useful bug fix |
…55673) * plugin module from breaking on invalid external_view destination * Added Test Case - For invalid plugin * Suggested Change Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> * Suggested Change Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> * Suggested Change Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> * Suggested Change Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> * suggested change as per feedback * Modified the total plugin count in testcases * validation done before pagination --------- Co-authored-by: Ash Berlin-Taylor <ash_github@firemirror.com> (cherry picked from commit ba00da4)
This PR fixes an issue where an invalid plugin definition (e.g., an unsupported destination in external_views) caused the entire /plugins API endpoint to fail with a 500.
Closes : #55571
With this change:
Added validation when constructing PluginResponse objects.
Only valid plugins are returned in the /api/v2/plugins API response.
Invalid plugins are skipped gracefully.
A warning is logged in the terminal with the plugin name and the error details.
This ensures the UI remains functional even if some plugins are misconfigured.
Impact:
Attached screenshot for reference
