Skip to content

Clarify stream closing semantics for bidirectional components #17997

Description

@jrudolph

As shown in #17992 a bidirectional components can easily provoke a race when the component is about to finish. When that happens completing the downstream side (regularly or with an error) is potentially racing against cancelling the upstream side.

Eventually, both must be done, but a better solution might be to complete the downstream side first, then wait for a grace period for the error to bubble through the counterpart in some form and only then cancel the upstream. The reasoning is that, especially in cases of an error, cancelling isn't able to transport any explanation about why the cancellation happened.

Metadata

Metadata

Assignees

No one assigned

    Labels

    1 - triagedTickets that are safe to pick up for contributing in terms of likeliness of being acceptedt:stream

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions