Skip to content

4.x: Stream ID can leak when InFlightHandler fails after acquisition #1002

Description

@dkropachev

Problem

InFlightHandler.write() transfers ownership of a pre-acquired reservation and acquires a concrete stream ID before building and registering the outbound frame. If a synchronous failure occurs after streamIds.acquire() but before the request is installed in the in-flight map, that concrete stream ID is not released.

This is a different ownership phase from #947: #947 covers failures before a request is submitted to InFlightHandler; this issue covers failures after InFlightHandler has accepted ownership and acquired the concrete ID.

Reproduction

Use protocol V3 and submit a request with a custom payload. Frame.forRequest() rejects the unsupported payload after the stream ID has been acquired. With a two-ID generator, the failed write leaves only one ID available.

The same cleanup gap should be audited for any exception between streamIds.acquire() and successful insertion into the in-flight map.

Impact

Repeated encoding or registration failures can permanently reduce the connection stream-ID capacity until the connection is discarded.

Expected behavior

Once InFlightHandler acquires a concrete stream ID, every synchronous failure before successful request registration must release it exactly once.

Scope relationship

Follow-up to #947 and intentionally excluded from #965, whose scope is limited to releasing pre-acquired reservations before submission and making those submission paths rejection-safe.

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