Skip to content

Validate plugins in /plugins API and skip invalid ones with warnings#55673

Merged
pierrejeambrun merged 9 commits intoapache:mainfrom
Brunda10:plugin_validation_fix
Sep 18, 2025
Merged

Validate plugins in /plugins API and skip invalid ones with warnings#55673
pierrejeambrun merged 9 commits intoapache:mainfrom
Brunda10:plugin_validation_fix

Conversation

@Brunda10
Copy link
Copy Markdown
Contributor

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:

  • Prevents the entire /plugins API from failing due to a single invalid plugin.
  • Users will continue to see all valid plugins in the UI, while still being informed about invalid ones through logs.

Attached screenshot for reference
Screenshot from 2025-09-15 17-49-50

Copy link
Copy Markdown
Member

@pierrejeambrun pierrejeambrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one comment.

Copy link
Copy Markdown
Member

@jason810496 jason810496 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ashb
Copy link
Copy Markdown
Member

ashb commented Sep 16, 2025

After #52651, do we need to switch to structlog for Core API as well?

@jason810496 We can switch things over to log = structlog.get_logger(), but any uses of stdlib logging will automatically get captured/redirect to send via structlog too, so no, we don't have to change anything but we can.

Copy link
Copy Markdown
Member

@ashb ashb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Member

@pierrejeambrun pierrejeambrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@Brunda10
Copy link
Copy Markdown
Contributor Author

Thanks for the feedback @pierrejeambrun ,

I’ve updated the implementation to:

  • First validate all plugins and build the valid_plugins list.
  • Then apply pagination and total_entries only on the valid set.
  • Added a test case to validate pagination when invalid plugins are present, ensuring page size and offsets behave correctly.

Copy link
Copy Markdown
Member

@pierrejeambrun pierrejeambrun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice thanks

@pierrejeambrun
Copy link
Copy Markdown
Member

CI is failing, I'll rebase the PR to trigger it again.

Brunda10 and others added 9 commits September 18, 2025 13:49
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>
@pierrejeambrun pierrejeambrun merged commit ba00da4 into apache:main Sep 18, 2025
109 checks passed
@boring-cyborg
Copy link
Copy Markdown

boring-cyborg bot commented Sep 18, 2025

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

@bbovenzi bbovenzi added this to the Airflow 3.1.0 milestone Sep 18, 2025
@bbovenzi
Copy link
Copy Markdown
Contributor

Adding to 3.1 milestone. This feels like a useful bug fix

kaxil pushed a commit that referenced this pull request Sep 18, 2025
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:API Airflow's REST/HTTP API

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Whole plugin module breaks if user gives wrong destination for external_view plugin

5 participants