Upgrade Foundatio for atomic password-login admission #2655

Follow-up after #2601

PR #2601 now uses Foundatio's ICacheClient directly for one immutable admission state per account/window and IP/window. The provider-specific mutation lock, manual conditional-cache wrappers, and slot scanning have been removed in response to review. The application depends on atomic AddAsync, ReplaceIfEqualAsync, and RemoveIfEqualAsync across all supported cache implementations. Empty states are conditionally removed so rejected requests at a saturated IP do not retain an empty account entry for every submitted email address.

The pinned Foundatio 13.0.4 in-memory implementation mutates a shared cache entry inside its dictionary-update callback. Concurrent conditional replacements can both accept the same expected state and lose an update. An immutable application payload does not fix that provider defect. Foundatio #570 contains the required upstream fix and is still open; a merged PR without a published package would also be insufficient.

This upgrade is a separate follow-up, not a prerequisite for Redis-backed adoption of #2601. Foundatio.Redis 13.0.4 performs conditional writes/deletes atomically on the server. The in-memory limitation remains until the dependency upgrade, including for self-hosted deployments that select in-memory caching.

Scope

Use a dedicated dependency-upgrade PR after #2601. Provider correctness and provider-specific concurrency regressions belong in Foundatio. Do not add a local Foundatio source reference, copy its implementations, restore an application-level in-memory lock, or add a Redis-only AuthService fixture.

Only #570 is a direct requirement of this admission design. If the chosen release also includes Foundatio #580, #582, Repositories #333, or Redis #191, review their affected consumers as part of the upgrade. They are not five separate prerequisites for the login implementation.

Acceptance criteria

• Identify the published package version containing Bump MailKit from 2.5.2 to 2.6.0 #570 and select compatible Foundatio, hosting, Redis, storage, and repository packages from the existing feeds. Review release notes and affected consumers.
• Verify the upstream cache-contract concurrency tests pass for supported providers, including conditional replacement/removal ownership and expiration. Synchronous application tests or Moq fault injection do not establish native provider atomicity.
• Run the application admission regressions against the released dependency set: account/IP caps before password verification, shared callers, failure accounting, at-most-once completion, stale success/recovery, expiration/eviction, cancellation, ambiguous writes, bounded waiting, and cleanup of empty account states after IP rejection.
• Keep AuthService on the ordinary cache abstraction with no provider-specific compatibility code. Restore simultaneous-completion coverage in the Basic authentication fixture after the provider fix; the current fixture deliberately controls completion order.
• Run the complete normal CI pipeline on the dependency-upgrade PR, and review cache latency/command counts under representative contention before rollout. Static operation counts are not a production performance measurement.

Track the released version and upgrade verification here.

Current application evidence

At #2601 commit 4bc67e654, 71 focused application tests passed locally, and all eight Basic cases passed again without retries. A separate local Redis 8.6 probe using the installed Foundatio.Redis 13.0.4 package, production serializer, and two independent clients passed 80 rounds of account/IP admission and failure accounting with 65 requests per round. The older-server Lua path was inspected but not runtime-tested. Live production configuration was not inspected; checked-in Kubernetes defaults select Redis.

These checks do not establish in-memory provider correctness. Verify simultaneous native writes again when the fixed packages are published.