Skip to content

Preserve empty query values in mapping matchers - #513

Merged
csernazs merged 2 commits into
csernazs:masterfrom
bensynapse:fix-empty-query-values
Oct 5, 2026
Merged

csernazs merged 2 commits into
csernazs:masterfrom
bensynapse:fix-empty-query-values

Conversation

@bensynapse

Copy link
Copy Markdown
Contributor

I run Live Tennis API.

MappingQueryMatcher now keeps empty query values. An expectation of {"flag": ""} matches both ?flag= and ?flag.
An empty dictionary rejects those requests. Repeated parameters keep their first value, even when it is empty, and MultiDict retains empty members.
The howto and release note describe the stricter matching for requests that previously lost blank parameters.

All 15 new cases fail before the fix, including requests sent through the server.
make test on Python 3.10.21 and make cov on Python 3.14.7 each pass 151 tests.
Both retain two environment skips and one expected failure. Native hooks, Python 3.14 typing, release note lint and package builds pass.

make doc succeeds with existing warnings. Python 3.10 typing reports an existing tomllib import error.
A clean strict docs build reports 64 warnings. Untouched master reproduces the typing error and the same warning texts.

@csernazs

csernazs commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Hi @bensynapse,

Your PR looks good, and I think it is a bug fix.

I'm thinking about if it could break existing code using pytest-httpserver. I think that there could be a case when someone expects some dictionary and they want to exclude the flag hones, eg. flag=&foo=123 then they will have a currently working code matching for {"foo": "123“}.

Could you write a test for it? (eg. passes with xfail strict=True now).

If this is the case I'd release your PR in a greater version bump (eg minor or major).

Release notes are managed by reno so if you want to volunteer, you could also add those. If not I can do it.

Thanks,
Zsolt

@bensynapse

Copy link
Copy Markdown
Contributor Author

Added the strict xfail test for flag=&foo=123 against {"foo": "123"}.
It passes with the previous parser and fails with this fix, confirming the compatibility break.
The Reno note now includes that example and the expected dictionary with "flag": "".

@csernazs

csernazs commented Oct 5, 2026

Copy link
Copy Markdown
Owner

Thanks!

I'll merge it now and release it very soon.

@csernazs
csernazs merged commit 6c34c35 into csernazs:master Oct 5, 2026
9 checks passed
@csernazs

csernazs commented Oct 5, 2026

Copy link
Copy Markdown
Owner

hi @bensynapse ,

Version 1.2.0 has just been released with your fix. Please give it a try, I built all the packages using pytest-httpserver in nixpkgs and this change caused no regression so I'm hoping this will be just fine.

Thanks for your PR!

Zsolt

@bensynapse

Copy link
Copy Markdown
Contributor Author

I tried the PyPI 1.2.0 release on Python 3.10 and 3.14. All 25 query matcher and HTTP query tests pass, including the empty-value regressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants