[Bug]: Schemas in query parameters don't work

[j616]

Actual Behavior

Query parameters with schemas are ignored when Unmarshalling

Expected Behavior

Query parameters matching a query parameter with a schema should be included in Unmarshall results.

Steps to Reproduce

Schema:

openapi: 3.1.0
info:
    title: Example
    version: "0.0"
servers:
  - url: 'http://example.com'
paths:
  /:
    get:
      parameters:
        - name: tag.{name}
          in: query
          schema:
              type: object
              patternProperties:
                  '^tag\.[A-Za-z0-9]+$':
                      type: string
                      pattern: '^[A-Za-z0-9]+$'
                  additionalProperties: false
        - name: baz
          in: query
          schema:
            type: string

Python script:

from openapi_core import OpenAPI
from openapi_core.contrib.requests import RequestsOpenAPIRequest
from requests import Request
import re

oas = OpenAPI.from_file_path('./exampleOas.yaml')
req = oas.unmarshal_request(RequestsOpenAPIRequest(Request(
    "GET",
    "http://example.com/",
    params={"tag.foo": "bar", "baz": "bat"})))

print(req)
# Returns
# RequestUnmarshalResult(errors=[], body=None, parameters=Parameters(query={'baz': 'bat'}, header={}, cookie={}, path={}), security={})

# Prove the regex works
print(re.search(r"^tag\.[A-Za-z0-9]+$", "tag.foo"))
# Returns
# <re.Match object; span=(0, 7), match='tag.foo'>

OpenAPI Core Version

0.19.5

OpenAPI Core Integration

requests

Affected Area(s)

unmarshalling

References

Such a pattern is described here and I've had confirmation on the OpenAPI slack here that this is the current best approach to describing pattern-based query parameter names.

This may be related to https://github.com/python-openapi/openapi-core/issues/250 but isn't completely related as it should work with the query default style of form.

Example of the use case I have for this.

Anything else we need to know?

No response

Would you like to implement a fix?

None

[p1c2u]

OpenAPI specification doesn't let Parameter object's name to be a template with schema patterm.

[j616]

@p1c2u Are you sure about that? As linked in the references above, I asked about this on the OpenAPI slack and was told by one of the spec maintainers that this should work.

[p1c2u]

@j616

https://swagger.io/specification/#path-templating

Path templating refers to the usage of template expressions, delimited by curly braces ({}), to mark a section of a URL path as replaceable using path parameters.

Each template expression in the path MUST correspond to a path parameter that is included in the Path Item itself and/or in each of the Path Item's Operations. An exception is if the path item is empty, for example due to ACL constraints, matching path parameters are not required.

Specification states clearly the Path templating refers to Path Item only.

Unfortunately I have no access to the OpenAPI slack.

[j616]

This isn't using path templating, though, as far as I'm aware. The curly braces in the name aren't serialised, but are used in my example above to consistently convey the variable component to a human user. The templating is actually carried out by the patternProperties part of the schema. I believe schemas are allowed here as they are called out in the allowEmptyValue description with regards to its interaction with Schema Objects, and stating that allowEmptyValues is only valid for Query Parameters.

[j616]

Unfortunately I have no access to the OpenAPI slack.

There is a link for joining the OpenAPI slack in the "Participate" menu on the OpenAPI website.

[p1c2u]

@j616 Unfortunately I didn't find any references in the slack to the specification that would validate your approach.

Per OAS 3.x there's no provision for:

• Pattern-based parameter names
• Templated parameter names (outside of path parameters using RFC 6570)
• Using schemas to define dynamic parameter names

When OAS references "Schema Objects" in parameter definitions (like with allowEmptyValue), it refers to the value validation of the parameter NOT the parameter name itself.

patternProperties works on object properties in request/response bodies, not on parameter names. The OAS specification doesn't define any mechanism for patternProperties to dynamically generate parameter names.

Your pattern is clear and would make sense but this approach is not supported by the OpenAPI specification.

[j616]

https://open-api.slack.com/archives/C0EDH2QKD/p1755211848023869?thread_ts=1754309646.541589&cid=C0EDH2QKD is the thread where I was told by one of the maintainers that this is the approach to use in 3.1 . I wonder if that thread is the better place for this discussion so that the spec maintainers can be involved?