Repository navigation
[Bug]: Schemas in query parameters don't work #1022
Description
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: stringPython 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 #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
Activity
p1c2u commentedon Dec 16, 2025
OpenAPI specification doesn't let
Parameter object's name to be a template with schema patterm.j616 commentedon Dec 17, 2025
@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 commentedon Dec 17, 2025
@j616
https://swagger.io/specification/#path-templating
Specification states clearly the Path templating refers to Path Item only.
Unfortunately I have no access to the OpenAPI slack.
j616 commentedon Dec 17, 2025
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
patternPropertiespart of the schema. I believe schemas are allowed here as they are called out in theallowEmptyValuedescription with regards to its interaction with Schema Objects, and stating thatallowEmptyValuesis only valid for Query Parameters.j616 commentedon Dec 17, 2025
There is a link for joining the OpenAPI slack in the "Participate" menu on the OpenAPI website.
p1c2u commentedon Dec 20, 2025
@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:
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.patternPropertiesworks on object properties in request/response bodies, not on parameter names. The OAS specification doesn't define any mechanism forpatternPropertiesto dynamically generate parameter names.Your pattern is clear and would make sense but this approach is not supported by the OpenAPI specification.
j616 commentedon Dec 20, 2025
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?