Skip to content

proxy: allow service updates while long-lived requests are active #266

Description

@hieblmi

Summary

ServeHTTP holds servicesMtx.RLock across service matching, authentication, external store/pricer calls, and the full reverse-proxy response. UpdateServices needs the write lock.

A hung backend request or long-lived gRPC/streaming response can therefore prevent configuration updates indefinitely.

Impact

One request can block operational changes such as updating a backend, changing authentication policy, or deploying an emergency configuration. This is especially problematic for services intended to maintain long-lived streams.

Proposed direction

Publish immutable service/backend generations:

  1. Acquire the read lock only long enough to capture the current generation.
  2. Release it before authentication and backend I/O.
  3. Track generation references while requests use it.
  4. Retire and clean up old generation resources after their references drain.

This should be coordinated with transport/pricer retirement so shortening the lock does not close resources still used by requests or metering reports.

Acceptance criteria

  • A long-lived request on generation A does not prevent publishing generation B.
  • The request continues safely on generation A.
  • New requests use generation B immediately after publication.
  • Retired resources are eventually reclaimed without races.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions