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

Investigate DB connection drop causing TRILOGY_CLOSED_CONNECTION 500s

Aperta
  • Qualcosa non va?
#2,118 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à
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
42/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
mysql, rails, ruby
Ambito
backend, databases

Direzione di ricerca

Inizia da config/database.yml e config/puma.rb, poi esamina le impostazioni di timeout di MySQL in produzione e i log del database intorno al 2026-08-09 05:09 UTC. Controlla le lacune relative al connection-pool e ai timeout elencate nell’issue, insieme al percorso dell’errore attraverso app/helpers/application_helper.rb. Il lavoro è completato quando la causa della perdita della connessione è confermata o esclusa e viene documentata una decisione appropriata sulla configurazione o sul retry.

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

Descrizione

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.
Lingua principale
Ruby
Stelle
15
Fork
28
Merge medio
1g 12m
PR unite (30g)
262

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

Tutte le issue di rubyforgood/awbw

Issue simili

Altre issue su Ruby

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.