## Motivation and Context
The OpenAPI plugin imports operations from a spec and lets the host
restrict which operations are exposed via an
`OperationSelectionPredicate` (and via `OperationsToExclude`). Operation
selection and request-URL construction should share one canonical
interpretation of an operation path. This change closes two consistency
gaps where a spec-supplied path could be interpreted differently at
selection time than at request time.
1. **Selection vs. request path normalization.** The selection predicate
received the raw operation path, while the request URL is built from a
canonicalized path. An encoded dot-segment (for example `%2e%2e`) is
textually different from the endpoint it canonicalizes to, so it could
pass a path-based include/exclude filter yet resolve to a different
route. Operations whose path contains an encoded or literal dot-segment
are now excluded before the predicate is consulted, symmetric with the
existing request-time dot-segment rejection.
2. **Request target reconciliation (defense in depth).** After the
request URL is built, verify it did not move off the configured server.
An operation path that is an absolute or authority-changing URI (for
example `https://another-host/admin`) carries no dot-segment, so it
passes path-segment validation, yet `System.Uri` / `urljoin` resolve it
to a different scheme, host, or port. Such a request is now rejected
before it is sent, so a credential-bearing request cannot be redirected
to an unintended target.
Both changes are applied symmetrically to the .NET and Python OpenAPI
ports.
## Description
- **.NET**
- `OpenApiDocumentParser` skips operations whose path contains a
dot-segment before invoking the selection predicate.
- `RestApiOperation` extracts a shared `ContainsDotSegment` helper
(reused by the existing `ValidatePathSegments`) and, after building the
request URL, reconciles its scheme/host/port and base path against the
configured server.
- **Python**
- `openapi_parser` skips dot-segment operations before the predicate
runs.
- `rest_api_operation` adds a shared `_contains_dot_segment` helper and
a post-construction `_ensure_request_target_matches_server`
reconciliation.
## Tests
- .NET: added selection-exclusion and request-target reconciliation
tests; full `Functions.UnitTests` OpenApi suite green (488).
- Python: added parity tests for both behaviors;
`tests/unit/connectors/openapi_plugin` green (173), ruff + ruff-format +
mypy + pre-commit clean.
## Contribution Checklist
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the SK Contribution Guidelines
- [x] All unit tests pass, and I have added new tests where possible
Update OpenAPI document parsing to gate file and HTTP ref resolution
separately.
### Breaking change
- `RESOLVE_FILES` is no longer enabled by default. Only internal JSON
pointer references are resolved by default.
- Users with multi-file OpenAPI specs must now pass
`enable_file_ref_resolution=True` via
`OpenAPIFunctionExecutionParameters`.
- `enable_external_ref_resolution` has been renamed to
`enable_http_ref_resolution`.
---------
Co-authored-by: Copilot <[email protected]>
Description
This PR enforces the presence of an explicit `operationId` for every
operation in the OpenAPI specification. Previously, if `operationId` was
missing, a default value was generated using the path and HTTP method.
Now, the parser will raise a PluginInitializationError if operationId is
not provided, ensuring that all operations are uniquely and explicitly
identified as required by the OpenAPI standard.
Key changes:
- Added validation to check for the existence of operationId in each
operation.
- If operationId is missing, a clear error is raised, preventing
fallback to a default value.
-
[python/tests/unit/connectors/openapi_plugin/no-operationid-openapi.yaml](https://github.com/microsoft/semantic-kernel/compare/main...sshandilya1991:semantic-kernel:sshandilya/12443_add_operation_id_validation?expand=1#diff-3d272039b3afa97f89805f0ee0258a98b613f0f373c603467b336a8912d5651a)
serves as a test case.
- Closes#12443
Edit:
- Added more validation for operationId to be unique & throw in case
duplicate operationId found while parsing.
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
Fixes to include AudioContent for MCP
Small typing improvement in OpenAPI.
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Motivation and Context
Dotnet had long removed the OpenAI plugin from its code base, and Python
did not follow at the time. We had previously provided deprecation
messages around using the OpenAI plugin and to switch to the OpenAPI
plugin. We are now removing the OpenAI plugin from the SK Python SDK.
Additionally, there was a forward reference created without specifying
the direct predicate context reference in the
OpenAPIFunctionExecutionParameters. This put the burden on the dev to
have to perform a model rebuild once the import was added. This PR
cleans up the `OperationSelectionPredicateContext` import, which is now
direct and via the sub-module and not via the parent module, which
causes the __init__.py to load all dependencies (which is unnecessary).
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
This PR:
- removes the unsupported OpenAI plugin (previously marked as
deprecated)
- fixes the `OperationSelectionPredicateContext` import to allow a user
to create the func exec params without receiving a pydantic error.
- updates unit tests to remove references to OpenAI plugin.
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
### Motivation and Context
We currently handle OpenAPI plugins via the kernel, but in a pretty
simple way. The changes in this PR are allowing one to define multiple
server paths for an operation as well as configure security on the
operations either at the operation level or at the "global" spec level
(these are included as metadata in the kernel function parameter
`additional_parameters` dict).
The OpenAPI plugin is graduating from an experimental state to a preview
state. This, in turn, removes the `experimental` tag from some public
facing methods. In the near future, all `experimental` tags will be
removed once we're confident there are no other underlying changes
required.
Closes#9719
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
Adds support for OpenAPI plugin:
- allow for multiple servers for an API operation
- allows one to define security configuration at the spec level as well
as per operation level
- fixes a bug where the `excluded_operations` on the execution settings
were never checked during REST API operation building
- adds the deprecated tag to the `OpenAI plugin` code as it was
deprecated by OpenAI and we never handled it in SK Python.
- renames some model class to remove the `operation` portion of the
name.
- adds ability to specify a callback to be able to skip certain api
operations based on name, method, or description
- removes the experimental tag from public facing methods.
- allows one to pass in a parsed OpenAPI spec to the plugin add method
- adds unit tests
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [ ] I didn't break anyone 😄
### Motivation and Context
We have mypy enabled on parts of the code base, but not all. The goal is
to enable it across the entire SK python code. As part of this, we've
broken up the work to tackle different sections. Additionally, we're
working to improve the code coverage for these sections of code.
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
This PR:
- turns on mypy for the openapi connector (plugin). Code adjustments
were made per mypy, with the exclusion of two places that contain a
`type: ignore` as the type was already valid, but mypy still complained.
- adds more unit test coverage for the OpenAPI models and classes. All
OpenAPI classes are now >95% covered.
- closes#7135
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
Added a section on documentation to the DEV_SETUP
Added a check for the copyright row to pre-commit
Closes#5629
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Motivation and Context
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
- Added static code checking to pre-commit (check-ast and
nbqa-check-ast)
- Added Bandit security checking to pre-commit
- Added pre-commit step to python-lint workflow, if it works, can delete
seperate mypy, ruff and black tests
### Description
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [x] The code builds clean without any errors or warnings
- [x] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [x] All unit tests pass, and I have added new tests where possible
- [x] I didn't break anyone 😄
### Motivation and Context
Building the tools json payload from the kernel parameter metadata
wasn't properly including an object of type `array`.
<!-- Thank you for your contribution to the semantic-kernel repo!
Please help reviewers and future users, providing the following
information:
1. Why is this change required?
2. What problem does it solve?
3. What scenario does it contribute to?
4. If it fixes an open issue, please link to the issue here.
-->
### Description
Correctly include the object type `array` so that the tool call doesn't
return a bad request. Add unit tests.
- Closes#6367
- Closes#6360
- Fixes the FunctionResult return for a type string -- if the
FunctionResult is of type KernelContent then return the first element of
the list, otherwise return the complete list.
- Fix the kernel function from method to include the proper type_object
for the return parameter so that the schema can be created properly.
- Add retry logic for a sometimes flaky function calling stepwise
planner integration test.
- Add a check during function calling that makes sure the model is
returning the proper number of arguments based on how many function
arguments are required.
<!-- Describe your changes, the overall approach, the underlying design.
These notes will help understanding how your code works. Thanks! -->
### Contribution Checklist
<!-- Before submitting this PR, please make sure: -->
- [X] The code builds clean without any errors or warnings
- [X] The PR follows the [SK Contribution
Guidelines](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
and the [pre-submission formatting
script](https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md#development-scripts)
raises no violations
- [X] All unit tests pass, and I have added new tests where possible
- [X] I didn't break anyone 😄
Roger Barreto