G
YouTube TikTok Games
Skip to content

Allow accepting new connections during a graceful shutdown #3961

Open

Description

@howardjohn

Is your feature request related to a problem? Please describe.
We want a very specific behavior for graceful shutdowns in our hyper-based proxy. We set two deadlines, min (typically 5-10s), and max (could be much longer). We want the following sequence during shutdown:

  • t=0s: send GOAWAY on all HTTP2 connections and start responding with connection: close on all http1 requests. Continue to accept new connections, and handle them the same (GOAWAY/connection: close) them.
  • After min deadline: stop accepting new connections. Continue existing connections, with the same GOAWAY/connection: close.
  • After max deadline: shutdown everything.

The reason for the time when we accept new connections, but tell clients to go away, is that there is some time for the load balancers in front of the proxy (this could be something like AWS NLB, Kubernetes kube-proxy, etc) to de-register the proxy instance and stop sending traffic to it. So immediately dropping new connections results in downtime. However, during this time its nice to start to encourage clients to goaway, since its likely they will select another proxy instance (either because the fronting LB already de-registered the old instance (the min deadline is intended to be the worst case, so usually its much faster), or because of random chance it selects a different one).

Today, the best we can do is wait until after min deadline and stop accepting new connections and start GOAWAY/connection: close at the same time.

Describe the solution you'd like
A new flag on hyper_util::server::conn::auto, and on hyper::server::conn::http1 to enable the "different graceful shutdown mode" (naming TBD!). This would change:

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context

If these changes are acceptable I would be happy to contribute both parts of the change

Activity

  1. added
    C-featureCategory: feature. This is adding a new feature.
    on Oct 7, 2025
  2. seanmonstar commented on Oct 7, 2025

    @seanmonstar
    Member

    Just to focus on HTTP/1 at first, this seems already possible, since hyper doesn't get involved with accepting new connections. You have control over when you would like to trigger the graceful_shutdown on any hyper::server::conn. Is there a piece I've missed that prevents you from doing that?

  3. howardjohn commented on Oct 7, 2025

    @howardjohn
    ContributorAuthor

    @seanmonstar the problem is I want, for any given response on a connection, to return connection: close. However, I do not want to reject a new request on the connection (or at least, I don't want to reject the first one; I don't mind rejecting them if they ignore my connection: close I suppose).

    But if I call graceful_shutdown, this ends up calling Dispatcher::disable_keep_alive which calls self.close() if there has not been any data (here

    self.state.close();
    and here
    if self.conn.is_write_closed() || self.conn.has_initial_read_write_state() {
    ).

    So what I want is really a way to just call State::disable_keep_alive, without the abstractions over it in Dispatcher and Conn which conditionally close the connection as well.

  4. added
    C-featureCategory: feature. This is adding a new feature.
    B-rfcBlocked: More comments would be useful in determine next steps.
    and removed
    C-featureCategory: feature. This is adding a new feature.
    on Aug 28, 2026
  5. added
    B-rfcBlocked: More comments would be useful in determine next steps.
    and removed
    B-rfcBlocked: More comments would be useful in determine next steps.
    on Sep 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-rfcBlocked: More comments would be useful in determine next steps.C-featureCategory: feature. This is adding a new feature.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions