Repository navigation
fix: resolve external 3.x payload references - #59
VisualBean merged 4 commits into
Conversation
|
Warning Review limit reachedYou've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. Next included review available in 14 minutes. View limit details
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
In 3.x a message payload reference is an AsyncApiMultiFormatSchemaReference. Resolving an external reference only handled JSON and Avro schema references, so an external payload such as `$ref: './payload.json'` was never read and reported "Unable to deserialize reference". The external content is now read as a Multi Format Schema Object, which also accepts a plain Schema Object. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
37032b6 to
87a19e9
Compare
|
Note that this doesnt solely touch external references. It also touches references where the initial pass or stored ref (in the workspace) doesnt resolve properly. We fall back to |
ResolveStreamReference is also the fallback for local references that are not in the workspace, not only for external ones. In a 2.x document every local payload reference is an AsyncApiMultiFormatSchemaReference, so the fallback asked the 2.x reader for an AsyncApiMultiFormatSchema loader it did not have and Read() threw KeyNotFoundException. The 2.x reader now loads a Multi Format Schema by reading the payload as a JSON Schema and wrapping it, since 2.x keeps schemaFormat on the message. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@VisualBean Good point, and it did matter here. I checked the local fallback with a payload
Fixed in ed63267: the 2.x reader now has a Multi Format Schema loader that reads the payload as a JSON Schema and wraps it, matching how 2.x keeps |
|
Please add an avro version of the |
Adds LocalAvroPayloadReference_NotInWorkspace_ResolvesPayload for 2.6.0
and 3.0.0, as requested in review.
The 2.x case failed. For a 2.x document, the whole-document stream that
the local fallback reads is the upgraded document serialized as 3.0, so
an Avro payload appears there as a Multi Format Schema Object
({ schemaFormat, schema }). The 2.x loader read it as a JSON Schema and
reported "schemaFormat/schema is not a valid property". The 2.x reader
now uses the 3.x Multi Format Schema loader for that fallback.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@VisualBean added and found bug related to it! |
Found while adding 3.x tests for #56.
In 3.x,
payload: $ref: ...is read as anAsyncApiMultiFormatSchemaReference. When an external reference is resolved, theSchemacase only handledAsyncApiJsonSchemaReferenceandAsyncApiAvroSchemaReference, so nothing was read for a payload reference. Every external 3.x payload reference, with or without a fragment, failed withUnable to deserialize reference '…'. This happens onvnexttoday and doesn't depend on #56.The external content is now read as a Multi Format Schema Object. That also accepts a plain Schema Object, which the spec allows as a payload.
Wrapping the reference in a multi-format object (
payload: { schemaFormat, schema: { $ref } }) already worked, because that goes through the JSON-schema path.Testing
$refis kept when the document is written back. All 3 fail without the fix.dotnet test: 405 passed on net8.0, net9.0 and net10.0.🤖 Generated with Claude Code