fix(common-openapi): resolve full servers[] precedence in OpenapiOperationView#2026
Merged
Conversation
…ationView Wire path-item-level servers[] through OpenapiPathView into OpenapiOperationView so operation.servers resolves operation > path-item > root precedence per the OpenAPI spec, instead of skipping the path-item level entirely. Also mirror OpenapiView's empty-configs handling so operation/path-level servers aren't silently dropped when no server configs are supplied. Make server URL variable resolution explicit: a templated server URL whose configured override doesn't match the declared variable pattern now throws OpenapiException instead of silently falling back to the variable's default value. Non-templated server URLs are unaffected since there is no variable to mismatch against. Closes #2020
…able mismatch Revert the OpenapiException-on-mismatch behavior added for server URL variable resolution. binding-mcp-openapi already treats a configured server URL as an unconditional override elsewhere (resolveServerOverride bypasses common-openapi's matcher entirely), and OpenapiOperationView.servers cross-products every model server against every configured override, so a non-matching pairing is the expected case whenever more than one server or config is present, not a misconfiguration. Throwing there would break that case rather than catch a real error.
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 free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 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.
Description
OpenapiOperationView.serverspreviously only reflected an operation's ownservers[]array, falling straight back to the root/document-levelservers[]when absent — it never looked at path-item-levelservers[]. This change wires the path-item'sservers[]throughOpenapiPathViewintoOpenapiOperationView, sooperation.serversnow resolves the full OpenAPI precedence: operation-level > path-item-level > root-level.While implementing this,
OpenapiOperationView(and, by extension, the new path-item level) also now mirrorsOpenapiView's handling of an emptyconfigslist — previously, an operation or path declaring its ownservers[]combined with an empty server-config list would silently resolve to zero servers instead of falling back to using the model's own server URL directly.The issue also raised the silent-fallback-on-mismatch behavior in
OpenapiServerView.VariableMatcher(a caller-supplied server URL override that doesn't match the variable's allowed pattern silently substitutes the declared default). After investigation, this PR intentionally leaves that fallback as-is:binding-mcp-openapialready treats a configured server URL as an unconditional override elsewhere (itsresolveServerOverridebypassescommon-openapi's matcher entirely), andOpenapiOperationView.serverscross-products every model server against every configured override, so a non-matching pairing is the expected outcome whenever more than one server or config is declared — not a misconfiguration to reject.This is a building block for downstream work (e.g.
binding-openapi-asyncapi) that currently duplicates parts of the servers[] precedence logic; simplifying that downstream duplication is left for a follow-up change.Testing
Added unit tests in
OpenapiViewTestcovering:servers[]taking precedence over path-item and rootservers[]taking precedence over root when the operation declares noneservers[]fallback when neither operation nor path-item declare any./mvnw test -pl runtime/common-openapipasses, along with the existing test suites forbinding-openapi,binding-openapi-asyncapi, andbinding-mcp-openapi.Fixes #2020