fix(web): correct idempotent replay payload and serialize concurrent duplicates

[marcelo-maciel]

Fixes the idempotency filter. It started as three defects (audit findings API-01 and CONC-01, plus a replay path that never engaged) and grew after review: re-reading the whole filter rather than the delta surfaced the rest, listed at the bottom.

API-03 (root): replay never engaged, even in production

The write went through HybridCache.SetAsync while the probe read IDistributedCache by the raw key. HybridCache keys its L2 entries under its own scheme, so the raw-key probe never found the entry and idempotency replay silently never engaged, not just in tests. The repo's ChatSendMessageTests replay test was skipped with this exact symptom attributed to a "test-env cache split"; un-skipping it proves it was the filter.

Fix: write to the same IDistributedCache, key and serializer the probe uses. Idempotency entries are short-lived (TTL) and their HybridCache tag-purge path was unused, so dropping HybridCache here loses nothing.

API-01: replay served the wrong shape and status

The filter cached SerializeToUtf8Bytes(result) where result is the wrapped IResult (Ok<T>/Created<T>), storing {"value":{...},"statusCode":200} instead of the wire DTO, and read Response.StatusCode before the IResult executed, so a 201 replayed as 200. The handler result is now executed into a buffer to capture the real wire body and status.

CONC-01: concurrent duplicates both executed

probe -> execute -> write had no atomic reservation, so two concurrent same-key requests both ran the handler. An atomic in-flight reservation now serializes duplicates: Redis SET NX when an IConnectionMultiplexer is registered (the multi-instance case, where this stack already requires Redis for the shared Data Protection key ring), an in-process set otherwise (single instance). A duplicate in flight gets 409 Conflict. Redis stays optional.

What review added

• The response is stored before the body reaches the client and on CancellationToken.None, so the timeout-then-retry that idempotency exists to absorb replays instead of re-executing.
• Replay carries the allow-listed headers Location and ETag, set while the IResult executes and previously dropped.
• Only 2xx is stored. A failure is not a record of a committed side effect, and caching it locked the caller out of that key for the full TTL.
• The key is scoped to the resolved tenant, the caller, the HTTP method, the route pattern and the resolved route values. Tenant alone let one key replay another endpoint's response, and a root operator acting on two tenants shared one bucket.
• The reservation is sound under the races it exists for: re-probe once the lock is held, lock: prefix instead of a suffix on the entry key, compare-and-delete release against the reservation's own token, and the in-process fallback expires on ReservationTtl.
• The handler runs with HttpContext.RequestAborted detached. A client hanging up after the side effect committed used to cancel the handler's next await, leaving nothing to store. The trade-off, that a disconnect no longer aborts an idempotent handler, is called out in the review thread and in the docs.
• Probe, reservation and store all fail open; a handler that writes to Response itself is passed through; the 409 carries Retry-After: 1; IdempotencyOptions is validated on start.

Tests

IdempotencyEndpointFilterReplayTests (33 cases) covers each branch: replay preserves 201 and the plain DTO body, allow-listed headers only, concurrent duplicates execute once with the loser getting 409, probe and store failures fall through to execution, reservation release under a thrown handler. OptionsDefaultsTests pins the startup validation. ChatSendMessageTests.SendMessage_Should_Replay_Same_Response_When_Idempotency_Key_Reused is un-skipped and passes against real Redis. Every fix was mutation-tested: 22 mutations, each reverting one fix, each required to turn its pinning test red, 22 of 22 red.

Docs

fullstackhero/docs#240, including the changelog entry and the documented ceilings (buffered response has no size cap, so not for streaming endpoints; no lease renewal; cross-instance dedup depends on the cache being on Valkey).

Unrelated: one dependency pin, so CI can run at all

build(deps): pin SSH.NET to the patched 2026.0.0 is not part of this fix. The Testcontainers packages pull SSH.NET 2025.1.0 transitively, and that version now carries GHSA-q939-rpr3-3284 (CVE-2026-48798, high). Under TreatWarningsAsErrors the advisory surfaces as NU1903 as an error, so dotnet restore src/FSH.Starter.slnx fails on main and on every open PR — Backend CI, CodeQL and the template smoke build all die before a single test runs. Testcontainers 4.11.0 and 4.13.0 both depend on 2025.1.0, so bumping Testcontainers does not clear it; 2026.0.0 is the first patched release. Transitive pinning is already enabled, so the one entry is enough, in the same block and the same shape as the MessagePack, Microsoft.OpenApi and SQLitePCLRaw pins already there. Happy to split it out if you would rather land it on its own.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[iammukeshm]

The three fixes are the right idea — same-store/same-key symmetry, buffer-and-capture for the true wire body+status, and an atomic SET NX / TryAdd reservation with re-probe-on-race. Tenant isolation is preserved (reservation key derives from the tenant-scoped cache key). Two things to fix before merge:

🔴 HIGH — reservation TTL is the 24h response TTL; a crash mid-request strands the lock for a day. The in-flight reservation uses options.DefaultTtl (24h). If the process is killed between reserving and the finally release (OOM, pod eviction, SIGKILL), the Redis key survives 24h and every retry of that idempotency key 409s for a full day. Use a short, request-timeout-scale TTL for the in-flight reservation (seconds/minutes), decoupled from the 24h stored-response TTL.

⚠️ MEDIUM — reservation now fails closed on a Redis blip. StringSetAsync is treated as authoritative, so a transient Redis error throws and 500s the request. On main idempotency degraded gracefully (convenience, not correctness). Wrap the reserve/release in try/catch and fail open (proceed) to match the existing stance used for the response write.

nit — ReleaseReservationAsync's KeyDeleteAsync is unguarded; a Redis fault at release throws out of finally and (with the TTL issue) strands the lock. Make it best-effort too.

⚠️ Also touches protected src/BuildingBlocks/Web (Golden Rule #4) — needs explicit maintainer sign-off.

Tests are good (replay shape + concurrent-once/409, integration un-skipped); note the concurrent path only exercises the in-process branch, not the Redis NX branch.

[marcelo-maciel]

Addressed in 08b34dcc.

🔴 HIGH — reservation TTL. Split out IdempotencyOptions.ReservationTtl (default 1m), decoupled from the 24h DefaultTtl. The reservation now keys to the short TTL, so a SIGKILL between reserve and the finally-release frees the lock in ~1m instead of stranding it for a day. Documented the constraint on the option: it must outlast the longest handler runtime or a concurrent duplicate can slip through.

⚠️ MEDIUM — fail closed on Redis blip. TryReserveAsync now wraps StringSetAsync in try/catch (ex is not OperationCanceledException) and fails open (proceeds), logging a warning — same best-effort stance as the response write. A transient Redis error no longer 500s the request; the response cache still dedups later retries.

nit — unguarded release. ReleaseReservationAsync's KeyDeleteAsync is now best-effort under the same filtered catch, so a Redis fault can't throw out of the finally. The short ReservationTtl expires a missed delete anyway.

Redis NX branch coverage. Added two unit tests over a substituted IConnectionMultiplexer: one asserts the reservation TTL is ReservationTtl and not DefaultTtl (guards the HIGH fix from regressing), the other faults both StringSetAsync and KeyDeleteAsync and asserts the handler still runs without throwing. Framework suite green (126/126).

Golden Rule #4 — src/BuildingBlocks/Web. Acknowledged; this needs your maintainer sign-off. The change is scoped to the Idempotency/ filter + options.

[iammukeshm]

The three blockers from my last review are properly fixed — ReservationTtl is decoupled and documented, reserve and release both fail open with the reasoning written down, and the release can no longer throw out of finally. The _ = ct discard is a bit odd but harmless.

Re-reading the whole filter rather than just the delta surfaced two things the previous pass missed. One of them defeats the feature's core promise, so requesting changes.

🔴 HIGH — the response cache write is cancelled by client disconnect, so the handler re-executes on retry

await distributedCache.SetAsync(
    cacheKey, payload,
    new DistributedCacheEntryOptions { ... },
    httpContext.RequestAborted).ConfigureAwait(false);   // <-- here

Walk the sequence that idempotency exists to defend against:

1. Client POSTs with an Idempotency-Key. Handler runs, side effect commits.
2. Client times out and hangs up. RequestAborted fires.
3. The SetAsync is cancelled — nothing is cached. OperationCanceledException is deliberately excluded from the best-effort catch, so it propagates.
4. finally releases the reservation.
5. Client retries with the same key. Probe misses, reservation is free, handler executes a second time.

Client-timeout-then-retry is not an edge case — it's the single most common way a duplicate request is generated, and it's the exact scenario the feature is for. The stored response is the durable record that the side effect already happened; its write must outlive the request that produced it.

Use CancellationToken.None for that SetAsync. The body write to the client on the line above should keep RequestAborted (no point writing to a dead socket), but the cache write must not.

While you're there: the catch (Exception ex) when (ex is not OperationCanceledException) around it will no longer skip cancellation once the token is None, which is what you want — a genuine cache failure stays a logged warning.

⚠️ MEDIUM — replay drops response headers, so a replayed 201 has no Location

ExecuteAndCaptureAsync captures status code, content type and body — nothing else. But executing an IResult is precisely when headers get set: TypedResults.Created(uri, value) writes Location. First call returns 201 + Location; the replay returns 201 with no Location. A client that follows the header on create works the first time and breaks on retry, which is the worst failure shape — it only shows up under the retry conditions nobody tests.

Capture the response headers into CachedIdempotentResponse and replay them. Filter to a safe set rather than replaying everything (skip Date, Server, Transfer-Encoding, Content-Length, and anything the host will set itself) — Location and ETag are the ones that carry meaning here.

note — non-2xx responses are now cached for the full 24h

This is pre-existing behaviour, not something you introduced, but this PR makes it bite. Previously the cached status was always the default 200 (the bug you're fixing), so a replayed error was already wrong in an obvious way. Now capture is faithful: a handler that returns 409, 429 or a 500-shaped IResult gets that status stored and replayed for DefaultTtl — 24 hours. A caller that hits a transient downstream failure is then locked out of retrying that key for a day.

Not blocking, because it's a change in an existing behaviour rather than a regression, but the right fix is small: only cache statusCode is >= 200 and < 300. If you'd rather do it here, I'll take it; if not, please open an issue so it doesn't get lost.

on the design, which is sound

Same-store/same-key symmetry is the correct diagnosis — a HybridCache write keying L2 under its own scheme while a raw-key IDistributedCache probe reads plain keys is exactly why replay silently never engaged, and why the integration test was skipped rather than failing. Buffer-and-capture is the right way to get the true wire shape, and returning Results.Empty rather than null to stop the framework appending a serialised null is a detail that would have caused a confusing bug.

Tenant isolation holds: the reservation key derives from the already tenant-scoped cache key.

Agreed that the in-process fallback is acceptable given multi-instance deployments in this stack already run Redis — the comment justifying it is the right way to record that assumption. As noted last time, the concurrency test only exercises the in-process branch; that's a reasonable limit for a unit test and I'm not asking for a Redis-backed one.

BuildingBlocks sign-off (Golden Rule #4)

Granted in principle for Web/Idempotency — the change is contained and the feature was measurably broken. Merging once the RequestAborted fix and the header capture land.

[marcelo-maciel]

Both blockers landed in 52365f34: the store runs on CancellationToken.None before the body reaches the client, and Location/ETag are captured and replayed off an allow-list. Your non-blocking note is in too, only 2xx is stored.

Then I did what you did, re-read the whole filter instead of the delta, and that turned into three more commits (53ef779b, b18e541c, 08fcadef, plus two test/doc commits). Please re-review from 52365f34, not from the diff you already approved. One of those changes is a semantic change to every endpoint carrying .WithIdempotency(), and I would rather you reject it now than discover it later.

The one that needs your call: the handler no longer sees client disconnect

The SetAsync fix you asked for closes the cancellation at the store. It does not close it inside the handler:

1. Client POSTs with a key. Handler commits the side effect.
2. Client hangs up. RequestAborted fires.
3. The handler's NEXT await, an EF read, an outbox write, a Mediator behaviour, throws OCE.
4. next(context) never returns a result. There is nothing to store, on any token.
5. Retry with the same key: probe misses, handler runs, side effect happens twice.

Same duplicate as before, one link upstream. So the handler now runs with the token detached and the original restored right after:

var originalAborted = httpContext.RequestAborted;
try
{
    httpContext.RequestAborted = CancellationToken.None;
    result = await next(context).ConfigureAwait(false);
}
finally
{
    httpContext.RequestAborted = originalAborted;
}

The cost is real and it applies to all 29 idempotent endpoints: a client disconnect no longer aborts the handler. An abusive client can open requests and hang up, and the work still runs to completion. That is the trade-off I am asking you to accept or veto.

The alternative I rejected: catch OperationCanceledException around next(context) and store anyway. There is nothing to store, the exception arrives instead of the result, so it buys nothing. Third option if the trade-off is unacceptable: leave the token attached, accept that a disconnect mid-handler means the retry re-executes, and document it as a known hole. I would take the current behaviour, but this is a framework other people ship, so it is your call, not mine.

Disclosures, since they are outside what you looked at

• The key shape changed again. It now folds in the resolved route values and the caller (GetUserId(), "anon" when unauthenticated) on top of tenant + method + route pattern. Two consequences: PUT /tickets/1 and PUT /tickets/2 stopped being one operation, and two users of one tenant reusing a low-entropy key stopped seeing each other's response bodies. It also means entries written before the deploy are unreachable. They expire on their own TTL, and a retry that lands inside the rollout window re-executes. Harmless today because replay never engaged, worth a line in the release notes.
• I touched src/BuildingBlocks/Caching/CacheKeys.cs, one XML comment, no code. Your sign-off was for Web/Idempotency/, so this is outside it. The doc said the entry is written with Tags.Idempotency for bulk invalidation; this PR is what stopped applying that tag (IDistributedCache has no tags), so the comment became false because of this change. I would rather fix it here than leave the lie in a shared file, but say the word and I will revert the line.
• Caller scoping is not inert. GetUserId() reads ClaimTypes.NameIdentifier only, and until f3d66c56 nothing proved that claim survives bearer validation of a real token. Every test built the principal by hand, so the scoping could have collapsed every caller into one bucket with a green suite. There is now a round-trip test through JsonWebTokenHandler configured with JwtBearerOptions' own MapInboundClaims default. I verified both shapes IdentityService emits: with the explicit ClaimTypes.NameIdentifier claim removed, the short-form sub maps to it and GetUserId() still resolves.

The rest of what landed

Reservation soundness (53ef779b): the entry is keyed on the resolved tenant rather than the tenant claim, and never on the raw header, which is unvalidated when Finbuckle did not resolve it. The cache is re-probed once the lock is held, because the original request can store and release inside the probe-to-reserve window. The lock lives under a lock: prefix instead of a :inflight suffix on the entry key: a caller key ending in :inflight could otherwise park a 24 h entry exactly where another key's lock goes and 409 that key for a day. Release is a compare-and-delete against the reservation's own token, so a request that failed open, or whose lease expired, cannot free a lock someone else holds. The in-process fallback expires on ReservationTtl like the Redis branch instead of stranding the key until restart.

Remaining holes (b18e541c): the probe was the one link that still hard-failed, so a Redis blip returned 500 on every idempotent endpoint for exactly the clients that send a key. It fails open as a miss now. A handler that writes to Response itself is passed through instead of having an empty capture stored and its status set after the response started. The 409 carries Retry-After: 1. And IdempotencyOptions is validated on start: a zero DefaultTtl used to throw inside the best-effort store, log a warning and carry on, so nothing was ever cached.

08fcadef is coverage only, and it is the commit I trust least on its own merits, so I gated it. Every fix above was mutation-tested: 22 mutations, each reverting one fix, each required to turn its pinning test red. 22 of 22 red, filter file restored byte for byte (sha256 1b167d75...). Two tests came back green under mutation on the first run and were rewritten: one exercised the in-process branch when the collision only exists in Redis, the other matched ScriptEvaluateAsync(Arg.Any<string>(), ...) while the fake hardcoded the Lua semantics. Both "covered" bugs that stayed reintroducible.

Deliberately not fixed, documented as ceilings instead

Three ponytail: comments in the filter rather than code, because each is a design decision I do not want to make unilaterally: no size cap on the buffered response, so do not put .WithIdempotency() on a streaming endpoint; no lease renewal while the handler runs, so a handler slower than ReservationTtl lets a duplicate through; and the lock's multiplexer may not be the cache's Redis, so cross-instance dedup depends on the cache being on Valkey. Also not done, each a separate PR if you want it: no request-body fingerprint, so same key with a different body replays the first response instead of returning 422, and Idempotency-Replayed is not in the CORS exposed-headers list, so browser clients cannot read it.

Docs: fullstackhero/docs#240, including the changelog entry and the ceilings above.

Verification on 5b33004a: 1087 unit tests pass locally across every test project (Integration.Middleware.Tests' 5 need Docker, which is not up on this box; they pass in CI), and CI is green on the same commit including Integration Tests and both scaffold builds.

[marcelo-maciel]

Two more things from an adversarial pass over the tests and the tenancy/keyspace, both verified at source. One is fixed in e6b0bb7e; the other is a decision I would rather you make.

Fixed: the startup-validation tests could not see whether validation happened at startup

OptionsDefaultsTests resolved IOptions<IdempotencyOptions>.Value, which validates on first access with or without .ValidateOnStart(). So the tests passed either way, and deleting .ValidateOnStart() would have moved the failure from boot to the first request carrying an Idempotency-Key, once per process, in production. They now go through IStartupValidator, which is what .ValidateOnStart() registers and what the host runs before serving traffic. Measured: with .ValidateOnStart() removed, 6 of the 10 tests fail; before the change, 0 did.

That is the second vacuous gate this PR has produced, which is why I mutation-test rather than trust a green suite.

Your call: /self-register is anonymous, so every caller shares the "anon" bucket

b18e541c folded the caller into the key, which closed the same-tenant/two-users collision for authenticated endpoints. It does not close it for anonymous ones, and there is exactly one: SelfRegisterUserEndpoint is .AllowAnonymous().WithIdempotency() with the tenant coming from the tenant header.

Concretely, two different people self-registering on tenant B, each sending a low-entropy key ("1", "retry"), build the identical entry key:

idem:t:<B>:anon:POST:/self-register:<K>

The second one replays the first registrant's cached 201 with the first registrant's RegisterUserResponse(UserId), and their account is silently never created. Same shape lets any anonymous caller pin a key in a tenant's anon bucket for the full 24 h TTL. It stays inside one tenant (the tenant is a hard prefix), so nothing leaks across tenants, and it was unreachable before this PR because replay never engaged. Making replay work is what puts it on the wire.

Three ways to close it, smallest blast radius first, and I do not want to pick for you:

1. Drop .WithIdempotency() from /self-register (one line, in the Identity module). Registration is already guarded by the unique-email constraint, so a genuine retry surfaces as a 400 rather than a duplicate account. Cheapest, and it takes the only anonymous idempotent endpoint out of the picture.
2. Fold a hash of the request body into the key. Closes it generally, for authenticated callers too, at the cost of buffering the request body on every idempotent endpoint.
3. Stripe semantics: same key + different body returns 422. The correct end state, the largest change, and the one I would rather send as its own PR with its own tests.

I would take (1) in this PR and open an issue for (3). Say which and I will land it.

Informational, pre-existing, not introduced here

ResolveTenant's claim fallback keys under the JWT tenant claim, while the side effect keys off the resolved Finbuckle context only. Those diverge for a JWT-only request with no tenant header, because UseMultiTenant() runs before UseAuthentication() and the claim strategy no-ops (the comment at MultitenancyModule.cs:104 says so). Such a request keys the entry by claim while the handler's TenantInfo is null, so the save fails: non-2xx, never cached, no replay and nothing leaked. Flagging it only so the fallback is not read as a hole, and because it is the reason the fallback exists at all rather than defaulting straight to "global".

[marcelo-maciel]

Addendum on the options tests, because the IStartupValidator fix exposed a second weakness in the same file.

Asserting only OptionsValidationException was not enough: a zero DefaultTtl also trips the ReservationTtl must not exceed DefaultTtl clause, so the row aimed at DefaultTtl passed on the wrong clause, and that clause could be deleted with all five rows still green. Each row now names the failure message it expects (75eb3b9b).

Per-clause mutation run, so the claim is measured rather than asserted:

header-name           RED on exactly 1 row
default-ttl           RED on exactly 1 row
reservation-positive  RED on exactly 1 row
reservation-bound     RED on exactly 1 row
max-key-length        RED on exactly 1 row
validate-on-start     RED on all 6 cases (IStartupValidator is unregistered)
Extensions.cs restored byte for byte

CI is green on 75eb3b9b.

[marcelo-maciel]

Went ahead with option (1) on the anonymous-caller collision, in 430122aa. Revert it if you prefer (2) or (3) instead.

/self-register drops .WithIdempotency(). A retry there is already safe without the filter, since the unique-email constraint rejects the duplicate, and it was the only anonymous idempotent endpoint.

Deleting one call leaves nothing stopping the next one, so the rule is now enforced rather than documented. WithIdempotency() attaches an IdempotentEndpointMetadata marker, because an endpoint filter is invisible in endpoint metadata and nothing could otherwise assert which endpoints are idempotent. IdempotencyWiringTests walks the endpoint map and fails when an AllowAnonymous() endpoint carries the marker, in the same shape as the existing AuthRateLimitWiringTests. A second test fails if the marker stops being attached, so the first cannot pass over an empty set.

Both gates are mutation-verified locally against Testcontainers:

put .WithIdempotency() back on /self-register  -> 1 of 2 red (the anonymous-endpoint test)
stop attaching the marker in WithIdempotency() -> 1 of 2 red (the discoverability test)
both files restored byte for byte

The docs page framed this as a caveat to work around with fresh UUIDs; it is corrected to state the rule, and the changelog entry is in (fullstackhero/docs#240). .agents/rules/security.md says it too, so an agent adding an endpoint reads it there.

Still yours to decide: the RequestAborted detachment from my earlier comment, and whether a request-body fingerprint (option 3, Stripe's 422 on key reuse with a different body) should be its own PR. This change does not close that one, it only removes the case where a low-entropy key from a different caller collides.

Unrelated and pre-existing, flagging because it bit me locally: dotnet build src/FSH.Starter.slnx now fails NU1903 on SSH.NET 2025.1.0 (a transitive dependency, GHSA-q939-rpr3-3284) for Integration.Tests and Integration.Middleware.Tests. It is not from this PR and CI is green on it, so I left it alone rather than bumping a package here.

[marcelo-maciel]

Three commits landed after my last comment and I never wrote them up, which is my fault — the first one matters most, because the alert it fixes still reads as open.

CodeQL alert 28 is fixed (7c2dcbaf)

The bot's cs/log-forging finding was correct. The Response.HasStarted pass-through warning logged operation, and operation folds in Request.Method, the resolved route values and the raw request path — three caller-controlled sources on one log line. It was the only such line in the filter; every other log already goes through HashKey(...), which is why nothing else was flagged.

That warning now logs the route pattern read off the endpoint's RoutePattern, a literal from the route table, which identifies the endpoint just as precisely. operation is unchanged where it feeds the cache key — the route values have to stay there, since PUT /tickets/1 and PUT /tickets/2 are genuinely different operations.

NU1903 on SSH.NET (c2046037) — and this one may want to come back out

I had flagged this as pre-existing and out of scope, then hit it hard enough to fix it here: under TreatWarningsAsErrors the advisory is an error, so dotnet restore src/FSH.Starter.slnx fails for the whole solution and Backend CI, CodeQL and the template smoke build all die at restore. The commit pins SSH.NET to 2026.0.0, the first patched release, in the same shape as the MessagePack / Microsoft.OpenApi / SQLitePCLRaw entries next to it.

The commit message says bumping Testcontainers doesn't clear it. That was true of 4.11.0 and 4.13.0, the versions I checked at the time, and it is no longer true: Testcontainers 4.14.0 pulls SSH.NET 2026.0.0 transitively, so the bump alone is sufficient. Verified on a restore of the full solution:

> Testcontainers.PostgreSql   4.14.0
> SSH.NET                                 2026.0.0
> Testcontainers                          4.14.0

So #1369 solves the same advisory without adding a transitive pin, which is the cleaner fix. If that one merges first, c2046037 here should be dropped during the rebase — otherwise it is a duplicate PackageVersion item, exactly the trap you caught on the System.Security.Cryptography.Xml pin in #1323. Happy to drop it now and let this branch depend on #1369, or keep it and drop it later; your call on which ordering you'd rather manage.

Test diagnosis, not a fix (b2770010)

UpdateTheme_Should_NotLeakAcrossTenants_When_RootOperatorTargetsTenantA was seen returning 401 instead of 204 twice on a loaded machine, then passed four runs in a row — including two with 14 of 16 cores saturated — and passes in isolation and in CI. A bare status assertion gave nothing to work with: JwtBearer's reason for rejecting the token is in the ProblemDetails body, which the test discarded.

The assertions now report method, URL and body on mismatch, exercised by expecting the wrong status on purpose so the failure message is known to carry the body. The cause is still unidentified and this test can still go red — I would rather say that plainly than have it read as closed.

Still with you

Unchanged from my 12 Aug comment: the RequestAborted detachment, and whether a request-body fingerprint (option 3, Stripe's 422 on key reuse with a different body) belongs in its own PR. Neither blocks this branch as it stands.

[marcelo-maciel]

Reopened as #1378.

This PR was closed automatically on 2026-09-14, when the head fork was deleted.
The branch and the commits are unchanged; the head commit is still 7c2dcbaf8c470657eae1320164c173fc4323c1b4.