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

Investigate DB connection drop causing TRILOGY_CLOSED_CONNECTION 500s

Abierto
  • ¿Algo no está bien?
#2,118 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
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
42/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
mysql, rails, ruby
Área
backend, databases

Línea de trabajo

Empieza con config/database.yml y config/puma.rb; después revisa la configuración de timeout de MySQL en producción y los logs de la base de datos alrededor de 2026-08-09 05:09 UTC. Comprueba las carencias del connection-pool y de los timeouts indicadas en el issue, junto con la ruta del fallo a través de app/helpers/application_helper.rb. Se considera terminado cuando la causa de la pérdida de conexión se haya confirmado o descartado y se haya documentado una decisión adecuada sobre la configuración o el retry.

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

Descripción

bug

Summary

Production threw ActiveRecord::ConnectionFailed: Trilogy::EOFError: trilogy_query_recv: TRILOGY_CLOSED_CONNECTION on GET / (home#index). The immediate symptom — a 500 on the public homepage — was patched in #2117 by making the decorative banner query degrade gracefully. This issue tracks the underlying cause: the DB connection itself was dropped mid-request.

The banner was just the first query on the page, so it was the messenger, not the culprit. Any request whose first DB query lands on a stale/dropped connection would have 500'd the same way.

What happened

  • Error: ActiveRecord::ConnectionFailed: Trilogy::EOFError: trilogy_query_recv: TRILOGY_CLOSED_CONNECTION
  • Where: ApplicationHelper#display_banner (app/helpers/application_helper.rb) → Banner.published — the first query rendered on the homepage layout
  • When: 2026-08-09 ~01:09 AM ET (2026-08-09 05:09:29 UTC)
  • Request: GET https://portal.awbw.org/, from a DigitalOcean Uptime Probe
  • Host: awbw-production-6d475b8bcc-7drhj (production, puma 7.2.1, pid 1)
  • Honeybadger request id: 0ca65b06-f379-4f9b-b884-126051804d96
  • Frequency so far: 1 occurrence

TRILOGY_CLOSED_CONNECTION / EOFError on trilogy_query_recv means the server closed the TCP connection and Rails then tried to run a query over that dead socket. This is a classic stale pooled connection: a connection sits idle in the pool longer than the server (or an intermediary) is willing to keep it, the far end closes it, and the next checkout reuses it without noticing it's dead.

Likely causes (to investigate)

Common reasons an idle pooled connection goes dead:

  1. MySQL wait_timeout / interactive_timeout on the DB server closing idle connections that Rails still holds in its pool.
  2. A proxy / load balancer idle timeout between the app and the database (e.g. a managed-DB connection pooler, k8s service, or DO managed DB idle cutoff) severing long-idle connections.
  3. A DB server restart / failover / maintenance at ~01:09 ET that dropped all live connections.
  4. No connection liveness/reaping config — see below; Rails isn't set up to proactively verify or recycle idle connections.

Current config (relevant gaps)

config/database.yml base anchor:

  • adapter: trilogy, pool: ENV["DB_POOL"] || 10
  • No checkout_timeout, reaping_frequency, idle_timeout, connect_timeout, or read_timeout set.

config/puma.rb: threads = RAILS_MAX_THREADS || 3 (so the default pool of 10 comfortably covers threads — pool exhaustion is not the issue here).

Rails/Trilogy do verify a connection on checkout in some paths, but there's no reaping_frequency/idle_timeout to proactively prune connections that have been idle long enough to be reaped by the server, and no explicit timeouts to bound a hung socket.

Proposed investigation / fixes

  • Check the production MySQL wait_timeout / interactive_timeout values and compare against how long connections sit idle in the pool.
  • Confirm whether there's a proxy/pooler (or DO managed-DB) idle timeout between app and DB, and its value.
  • Check DB server logs around 2026-08-09 05:09 UTC for a restart / failover / connection reset.
  • Consider setting reaping_frequency and/or idle_timeout in database.yml so stale connections are pruned before they're handed to a request.
  • Consider explicit connect_timeout / read_timeout so a dead socket fails fast and predictably.
  • Decide whether transient connection failures on read paths should be retried once (framework-level) rather than surfaced as 500s.

Notes

  • #2117 only prevents the banner from 500ing the page; it does not address the connection drop. If this recurs on other actions, that PR won't help them.
  • If this stays at 1 occurrence and correlates with a one-off DB restart/failover, this may be benign — but it's worth confirming rather than assuming.
Lenguaje dominante
Ruby
Estrellas
15
Forks
28
Merge medio
1 d 12 min
PR fusionados (30 d)
262

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 rubyforgood/awbw

Todos los issues de rubyforgood/awbw

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.