Uh oh!
There was an error while loading. Please reload this page.
Validate provider metadata list entries instead of ignoring them - #71104
Merged
Conversation
Lee-Wforce-pushed
the
queues-schema-items
branch
2 times, most recently
from
August 5, 2026 08:10
0af7ff4 to
a509680CompareLee-W
marked this pull request as ready for review
August 5, 2026 08:34
kaxil
reviewed
Aug 5, 2026
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
The items blocks for queues, plugins and task-decorators listed their field names directly under items, where they are not JSON Schema keywords, so the blocks were inert and any shape passed. A provider author following what those blocks appeared to document — a dict for queues, or a path key for a decorator — got no error and was quietly dropped by the consumers instead. Pinning each section to the shape the provider.yaml files and generated payloads actually use turns that into a failure at authoring time. The custom-provider howto named the same nonexistent path field. Raised in review of apache#70190.
The runtime schema is documented as deliberately looser than the development one, and its validate() call is unwrapped in provider discovery, so a single installed provider emitting an outdated entry shape would abort discovery for every provider in that process instead of costing just that entry a logged warning. The structural descriptions stay behind so the schema no longer documents a shape it never actually enforced.
Requiring the right keys does not stop a leftover one sitting beside them, so a stale `path:` next to a correct `class-name:` still validated — exactly the confusion this branch set out to remove. Every sibling item block in this authoring schema already closes itself off this way.
potiuk
approved these changes
Aug 9, 2026
Uh oh!
There was an error while loading. Please reload this page.
dabla pushed a commit
to dabla/airflow
that referenced
this pull request
Aug 14, 2026
…che#71104) * Validate provider metadata list entries instead of ignoring them The items blocks for queues, plugins and task-decorators listed their field names directly under items, where they are not JSON Schema keywords, so the blocks were inert and any shape passed. A provider author following what those blocks appeared to document — a dict for queues, or a path key for a decorator — got no error and was quietly dropped by the consumers instead. Pinning each section to the shape the provider.yaml files and generated payloads actually use turns that into a failure at authoring time. The custom-provider howto named the same nonexistent path field. Raised in review of apache#70190. * Keep runtime provider metadata validation permissive The runtime schema is documented as deliberately looser than the development one, and its validate() call is unwrapped in provider discovery, so a single installed provider emitting an outdated entry shape would abort discovery for every provider in that process instead of costing just that entry a logged warning. The structural descriptions stay behind so the schema no longer documents a shape it never actually enforced. * Reject unknown keys in provider.yaml decorator and plugin entries Requiring the right keys does not stop a leftover one sitting beside them, so a stale `path:` next to a correct `class-name:` still validated — exactly the confusion this branch set out to remove. Every sibling item block in this authoring schema already closes itself off this way.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
#70190 (comment)
The items blocks for
queues, plugins and task-decoratorslisted their field names directly under items, where they are not JSON Schema keywords, so the blocks were inert and any shape passed. A provider author following what those blocks appeared to document — a dict for queues, or a path key for a decorator — got no error and was quietly dropped by the consumers instead.What
Pinning each section to the shape the provider.yaml files and generated payloads actually use turns that into a failure at authoring time. The custom-provider howto named the same nonexistent path field.
Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.