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

Readiness stays 500 for 3h after a transient DB error during boot (TrackerScriptCache refresh_all never retried)

Abierto
  • ¿Algo no está bien?
#6,647 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@RaphaelFakhri ya está trabajando en esto.

Desde el 25/10/2026.

  • #6799 de @RaphaelFakhri — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
elixir, kubernetes, postgresql
Área
backend, databases, devops

Línea de trabajo

Start in lib/plausible/cache.ex with Plausible.Cache.Warmer, refresh/3, and refresh_updated_recently; then inspect system_controller.ex for ready?/1 and the critical-cache checks. Trace how a failed boot refresh is scheduled and how readiness observes an empty TrackerScriptCache. Done means the reported transient startup failure no longer leaves readiness failing until the multi-hour interval elapses, with the relevant behavior covered by the project's existing tests.

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

Descripción

Past Issues Searched

Searched for TrackerScriptCache / tracker_script_cache / readiness; nothing matching.

Version

Community Edition v3.2.1 (also checked master: same code in lib/plausible/cache.ex and system_controller.ex).

What happened

A single transient DB error during boot makes /api/health (readiness) return 500 for 3 hours, while the app otherwise serves traffic fine. Under Kubernetes with the documented health probe this becomes an infinite restart loop.

Sequence, from logs:

  1. At boot Plausible.Cache.Warmer runs refresh_all for every cache at once, plus Oban starts. With a 10-connection pool and a DB a few hundred ms away, the pool hit DBConnection.ConnectionError ... queue_timeout after ~6s.
  2. Plausible.Cache.refresh/3 catches that and only logs Error refreshing 'tracker_script_cache' - ... (cache.ex ~L233). The cache stays empty.
  3. TrackerScriptCache is in @critical_caches for readiness. ready?/1 returns false because size() == 0 but count_all() == 9. Readiness responds 500 {"sessions":"ok","postgres":"ok","clickhouse":"ok","sites_cache":null}.
  4. The next refresh_all for tracker_script_cache is scheduled ~3 hours out (interval 10805730 in the warmer init log). refresh_updated_recently runs every 30s but only picks up rows updated since the last run, so it never repairs a cache that missed the initial load.
  5. If the deployment's startup/liveness probe points at /api/health, the pod is killed long before 3h elapse, and the cycle repeats on every boot. I saw 56 consecutive restarts.

Plausible.Site.Cache and Plausible.Shield.IPRuleCache have the same shape but shorter refresh_all intervals (15 min / 3 min), so they self-heal before anyone notices.

Expected

A failed boot-time refresh_all should retry (short backoff) instead of waiting for the next multi-hour cycle, or refresh_updated_recently should fall back to a full refresh while ready?/1 is false.

Workaround

bin/plausible rpc 'Plausible.Site.TrackerScriptCache.refresh_all()' inside the container makes readiness green immediately. For Kubernetes, point startup/liveness at /api/system/health/live and keep /api/health for readiness only.

Lenguaje dominante
Elixir
Estrellas
29.7k
Forks
1.9k
Merge medio
3 d 22 h
PR fusionados (30 d)
50

Preparar el entorno

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 plausible/analytics

Todos los issues de plausible/analytics

Issues similares

Más issues de Elixir

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.