Thruster on Heroku - Delay binding to HTTP_PORT until TARGET_PORT is available?
- Dominant language
- Go
- Stars
- 1.2k
- Forks
- 58
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 6
Description
Hi,
We're on Heroku and hitting an issue fronting our app with Thruster. Apparently Heroku considers a dyno "up" as soon as a process binds to the [provided] $PORT variable, and starts directing traffic to it. The trouble is that that dyno is not ready to receive traffic yet as puma has not yet booted, so we're seeing a bunch of 502s / connection-refused logs from thruster during this interval.
Is it possible to delay binding to HTTP_PORT until the target port (puma) is available?
Or are there any other suggestions for avoiding this issue on Heroku (which does not use healthchecks as most other platforms do for directing traffic)?
We're using Thruster mainly for its X-Sendfile support + proxying to anycable (via the thruster-anycable fork).
Thanks!
Contributor guide
Research direction
Start by tracing Thruster's HTTP_PORT listener startup and how it checks TARGET_PORT or Puma availability. Reproduce the Heroku startup sequence and verify that traffic is not accepted before Puma is ready, while preserving X-Sendfile support and anycable proxying.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend, networking
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100