Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Upgrade Foundatio for atomic password-login admission

Abierto
  • ¿Algo no está bien?
#2,655 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
csharp, redis
Área
authentication, backend

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
C#
Estrellas
2.5k
Forks
508
Merge medio
2 d 17 h
PR fusionados (30 d)
40

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de exceptionless/Exceptionless

Todos los issues de exceptionless/Exceptionless

Issues similares

Más issues de C#

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.