Remove allOf JSON schema workarounds #10029
Merged
Conversation
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
CodSpeed Performance ReportMerging #10029 will not alter performanceComparing Summary
|
|
Hi,
Thanks, Dan |
15 tasks
|
Exciting stuff! Let's wait for @adriangb to review this on Monday - he's pretty familiar with this part of the codebase :). |
sydney-runkle
added
relnotes-change
This was referenced Aug 2, 2024
|
I'll note that I am in favor of this change, and my experience has been that many/most existing tools that interop with JSON schema behave as expected when sibling keys to a However, just as part of appropriate due diligence — can you share a reference that this is now allowed in JSON schema? In particular, I'm thinking we may need to reference a new draft version or similar. The FastAPI test failures can be white-listed if we want to move forward with this, there is an existing pattern for that I can dig up if there are no white-listed tests currently. |
|
I believe this might be what we're looking for: https://json-schema.org/draft/2019-09/release-notes#core-vocabulary |
8 tasks
sydney-runkle
suggested changes
Aug 7, 2024
There was a problem hiding this comment.
This looks great! Let's add an exception for the FastAPI failing test like was done for this one:
pydantic/tests/test_fastapi.sh
Lines 21 to 25 in 64a637b
Once we do that for the failing test, let's merge!
pydantic-hooky
bot
added
the
awaiting author revision
dpeachey
force-pushed
the
remove-all-of-json-schema-workarounds
branch
from
3cdfb81 to
708f1ca
Compare
sydney-runkle
approved these changes
Aug 8, 2024
|
@tiangolo, just wanted to notify you re this change, given that it broke one of the fastapi integration tests 👍 |
25 tasks
12 tasks
eadwinCode
added a commit
to python-ellar/ellar
that referenced
this pull request
Sep 9, 2024
This was referenced Sep 13, 2024
Merged
1 task
whiskeyriver
added a commit
to whiskeyriver/djantic2
that referenced
this pull request
Dec 8, 2024
Pydantic's json schema output changed after 2.8, eliminating the `allOf` wrapping of a single `$ref` element. See: pydantic/pydantic#10029 Here's a hacky way of ensuring tests run between these versions.
whiskeyriver
added a commit
to whiskeyriver/djantic2
that referenced
this pull request
Dec 8, 2024
Pydantic's json schema output changed after 2.8, eliminating the `allOf` wrapping of a single `$ref` element. See: pydantic/pydantic#10029 Here's a hacky way of ensuring tests run between these versions.
Mark90
added a commit
to workfloworchestrator/orchestrator-core
that referenced
this pull request
Mar 4, 2025
pboers1988
pushed a commit
to workfloworchestrator/orchestrator-core
that referenced
this pull request
Mar 5, 2025
* Update pydantic[email] requirement from ~=2.8.2 to ~=2.9.2 Updates the requirements on [pydantic[email]](https://github.com/pydantic/pydantic) to permit the latest version. - [Release notes](https://github.com/pydantic/pydantic/releases) - [Changelog](https://github.com/pydantic/pydantic/blob/main/HISTORY.md) - [Commits](pydantic/pydantic@v2.8.2...v2.9.2) --- updated-dependencies: - dependency-name: pydantic[email] dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com> * Remove 'allOf' from expected pydantic schema's Related change: pydantic/pydantic#10029 --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Mark90 <mark_moes@live.nl>
psychedelicious
added a commit
to ebr/InvokeAI
that referenced
this pull request
Mar 31, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to ebr/InvokeAI
that referenced
this pull request
Mar 31, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to ebr/InvokeAI
that referenced
this pull request
Mar 31, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
ebr
pushed a commit
to ebr/InvokeAI
that referenced
this pull request
Apr 2, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to ebr/InvokeAI
that referenced
this pull request
Apr 2, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to invoke-ai/InvokeAI
that referenced
this pull request
Apr 3, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to invoke-ai/InvokeAI
that referenced
this pull request
Apr 4, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to invoke-ai/InvokeAI
that referenced
this pull request
Apr 4, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
psychedelicious
added a commit
to invoke-ai/InvokeAI
that referenced
this pull request
Apr 4, 2025
In pydantic/pydantic#10029, pydantic made an improvement to its generated JSON schemas (OpenAPI schemas). The previous and new generated schemas both meet the schema spec. When we parse the OpenAPI schema to generate node templates, we use some typeguard to narrow schema components from generic OpenAPI schema objects to a node field schema objects. The narrower node field schema objects contain extra data. For example, they contain a `field_kind` attribute that indicates it the field is an input field or output field. These extra attributes are not part of the OpenAPI spec (but the spec allows does allow for this extra data). This typeguard relied on a pydantic implementation detail. This was changed in the linked pydantic PR, which released with v2.9.0. With the change, our typeguard rejects input field schema objects, causing parsing to fail with errors/warnings like `Unhandled input property` in the JS console. In the UI, this causes many fields - mostly model fields - to not show up in the workflow editor. The fix for this is very simple - instead of relying on an implementation detail for the typeguard, we can check if the incoming schema object has any of our invoke-specific extra attributes. Specifically, we now look for the presence of the `field_kind` attribute on the incoming schema object. If it is present, we know we are dealing with an invocation input field and can parse it appropriately.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Change Summary
The JSON schema spec was updated to allow sibling keys alongside
$refkeys so it is no longer required to wrap the$refkey in aallOfarray with a single$refelement. This change removes theallOfworkarounds.Related issue number
fix #6343
Checklist