Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Upgrade Foundatio for atomic password-login admission

Aperta
  • Qualcosa non va?
#2,655 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp, redis
Ambito
authentication, backend

Direzione di ricerca

Start by checking Foundatio #570 for a published package version, then review the compatible Foundatio, hosting, Redis, storage, and repository releases and their consumers. Run the upstream cache concurrency tests and the listed application admission regressions against that released dependency set, followed by the normal CI pipeline. Done means the supported providers pass the cache contract and the upgrade meets the acceptance criteria, including contention review.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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 #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.

Lingua principale
C#
Stelle
2.5k
Fork
508
Merge medio
2g 17h
PR unite (30g)
40

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di exceptionless/Exceptionless

Tutte le issue di exceptionless/Exceptionless

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.