basecamp / basecamp/thruster

Thruster on Heroku - Delay binding to HTTP_PORT until TARGET_PORT is available?

Open
#91 5 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.