Puma 4: Hammering Out H13s—A Debugging Story

Summary

Heroku investigated mysterious H13s—“Connection closed” without response—affecting Ruby applications during dyno deployments or scaling, especially at high traffic levels. The failure involved a race between SIGTERM shutting down Puma and the router’s separate system continuing to deliver a few requests, but comparison with other webservers indicated Puma needed to handle the condition. A reproduction used Rack applications that sent SIGTERM to Puma and themselves, plus parallel curl requests, reproducing curl exit code 52 and Heroku H13s. Debugging showed Puma relied on process termination to close accepted sockets; Puma 4 instead closes binder listeners before shutdown, allowing the router to retry connections while preserving responses for in-flight requests.

Takeaways

1. 1

   A dyno shutdown coordinates SIGTERM to its processes with a separate router operation, so a few requests can still reach Puma after shutdown begins.

2. 2

   Puma’s reproduction used parallel requests and recorded curl exit code 52, “Empty reply from server,” while deployment on Heroku produced H13 errors.

3. 3

   Puma 4 closes binder listeners before shutdown; this rejects incoming connections for router retry while allowing existing requests to finish.