[AsParameters]: reject unparseable values in collection query parameters (GH-3398)

[jeremydmiller]

Fixes #3398. Completes the job started in #3372 (shipped in 6.17.1/6.17.2), which explicitly left collection query binding as a follow-up.

Why this one is worse than a plain 400

An unparseable element of a multi-valued query string parameter was silently dropped by the generated binder. On a filtering endpoint the bound collection is typically an optional predicate:

if (request.Colours is { Length: > 0 })
{
    query = query.Where(x => request.Colours.Contains(x.Colour));
}

So ?colours=Purple (typo) did not fail the request — it silently removed the filter and returned an unfiltered 200 while the caller believed the results were filtered. That is a silently-wrong-answer failure mode, not a loud one, and it is unrecoverable downstream: null is indistinguishable from "parameter omitted", so FluentValidation's RuleForEach has nothing to iterate and NotEmpty().When(x => x.Colours is not null) never fires. Applies to int[] / Guid[] / long[] as well as enums.

The fix

ParsedArrayQueryStringValue (T[]) and ParsedCollectionQueryStringValue (List<T>, IList<T>, IReadOnlyList<T>, IEnumerable<T>) now accept the same rejectUnparseableValue flag ReadHttpFrame got in #3372, wired from WolverineHttpOptions.RejectUnparseableQueryValues through HttpChain. Both emit a shared StrictQueryBinding.WriteRejectionBlock: an element that is present but fails TryParse writes a 400 ProblemDetails naming the parameter (via the existing HttpHandler.WriteQueryValueParsingProblem) and exits the generated method.

Semantics match the scalar case exactly:

Request	Flag off (default, unchanged)	Flag on
?Colours=Red&Colours=Blue	200 — [Red, Blue]	200 — [Red, Blue]
(omitted)	200 — keeps initializer	200 — keeps initializer
?Colours=Purple	200 — null	400 ProblemDetails naming Colours
?Colours=Red&Colours=Purple	200 — [Red]	400 ProblemDetails naming Colours

The default is not changed; the flag stays opt-in through 6.x and flips to strict in 7.0. String collections are untouched (nothing to parse). Form/route/header binding untouched.

Decision: all-or-nothing binding

?colours=Red&colours=Purple rejects the whole binding rather than binding [Red] and dropping Purple. ASP.NET Core minimal APIs reject the request when any element of a bound collection parameter fails to parse (the binding failure is recorded and the pipeline returns 400) rather than yielding a partial collection, so this is also the minimal-API-compatible answer that #3372 set out to match. Independently it is the only defensible option: a partially-bound collection is exactly the silently-wrong-answer this issue is about — the caller asked to filter on two colours and would get results filtered on one, with a 200 and no signal. Silently nulling the whole collection is worse still. If the caller genuinely wants lenient element dropping, that is what the (default) flag-off behavior gives them.

Red → green evidence

Tests added to src/Http/Wolverine.Http.Tests/strict_query_string_binding.cs (strict + lenient hosts already in that fixture): enum array, int[], Guid[], List<int>, a direct int[] method argument, the mixed valid+invalid case, valid-values-bind, omitted-parameter-keeps-initializer, and two flag-off lenience tests.

Before the fix — exactly the six strict-mode assertions fail, and the lenient/omitted expectations already pass (proving the behavior change is confined to the flag):

Failed  one_bad_element_rejects_the_whole_collection
Failed  malformed_enum_array_element_returns_400
Failed  malformed_int_array_element_returns_400
Failed  malformed_guid_array_element_returns_400
Failed  malformed_generic_list_element_returns_400
Failed  malformed_collection_element_on_direct_method_argument_returns_400
Failed!  - Failed: 6, Passed: 17, Total: 23

After:

Passed!  - Failed: 0, Passed: 23, Total: 23

Full Wolverine.Http.Tests suite on net9.0: 844 passed, 0 failed, 10 skipped. dotnet build wolverine.slnx -c Release: 0 warnings, 0 errors.

Docs: docs/guide/http/as-parameters.md gains a "Collections" section under Strict Query String Binding with the behavior matrix and the all-or-nothing rationale; docs/guide/http/querystring.md notes collection coverage.

Thanks to @outofrange-consulting for the report (and for the scalar case in #3372).

🤖 Generated with Claude Code

[jeremydmiller]

Superseded by a clean branch — this one was accidentally cut on top of the GH-3385 branch in a shared working tree, so its diff carried three unrelated gRPC files. Same commit, rebased onto main. Reopening; no review time lost.