Skip to content

Stdio server transport is in a bad state #564

@i1bro

Description

@i1bro

Describe the bug
Stdio transport is the most convenient option in a distributed application, since you can pass a custom sink/source to it. However, the current implementation has a bunch of critical bugs:

  1. Client messages are processed sequentially. This means there can't be 2 requests being processed at once.
    If there's a pinger to check client liveness, the "pong" response from client won't be handled before the previous, maybe very long-running, request handler is finished.
    Also it blocks advanced protocol features like elicitation.
    Moved to StdioServer: messages should be processed concurrently #572

  2. Request handlers are launched on Dispatchers.IO

  3. The coroutine scope that's used in this transport is completely detached from the coroutine tree, which may cause leaks. Please add an optional CoroutineScope parameter

  4. Cancellation exceptions are being caught and not rethrown

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workinginternal-usersIssues and PRs raised by internal users

    Type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions