Skip to content

A path abandoned by its path idle timeout is never discarded when the peer has no state for it #804

Description

@HeikoBornholdt

Describe the bug
I use multipath with a per-path idle timeout (default_path_max_idle_timeout). I open a second path
to an address that turns out not to answer, so the path never validates and the peer never learns
that it exists.

noq gives that path up by itself once the idle timeout expires, as PathAbandonReason::TimedOut. But
it is never freed: no PathEvent::Discarded arrives, Connection::path keeps handing out a handle
for it and Path::status keeps answering, for as long as the connection lives.

The peer sends no PATH_ABANDON back, because it has no state for a path it never learned. Sending one
would probably help, but even without an answer there should be something that eventually frees the
path.

Relevant Logs
Here is a minimal reproducible example, your server and client examples with multipath turned on
and one path opened to an address that never answers:
1a26a8b...HeikoBornholdt:noq:self-abandoned-path-repro

# Terminal 1
$ cargo run --example server -- ./ --listen 127.0.0.1:4433

# Terminal 2
$ RUST_LOG=info cargo run --example client -- --host localhost https://127.0.0.1:4433/Cargo.toml
path PathId(1) open to 127.0.0.1:54245, which never answers: idle timeout 5s, nothing here closes it
staying connected for 30s
2026-09-12T17:31:42.804979Z  INFO client: path event event=Abandoned { id: PathId(1), reason: TimedOut }
path PathId(1) after 30s: still here, path_status() = Ok(Available)

There is no Discarded event in between, and none arrives however long the client lingers.

Expected behavior
The path is freed without the peer having to answer, which is what PathEvent::Abandoned promises:
"This event will always be followed by Self::Discarded after some time".

noq
Version: 1.3.0 @ 1a26a8b06

noq v1.3.0
├── noq feature "bloom"
│   └── noq feature "default" (command-line)
├── noq feature "default" (command-line)
├── noq feature "platform-verifier"
│   └── noq feature "default" (command-line)
├── noq feature "ring"
│   └── noq feature "default" (command-line)
├── noq feature "runtime-tokio"
│   └── noq feature "default" (command-line)
├── noq feature "rustls"
│   └── noq feature "default" (command-line)
└── noq feature "tracing-log"
    └── noq feature "default" (command-line)

Platform(s)
Desktop:

  • OS: Linux (Ubuntu 24.04.5 LTS)

lolwut

  • This issue was created by a human that thought critically about
    the issue being reported and wrote this as concisely and clearly
    as they could. Taking full responsibility for the issue being
    accurate.
  • This issue isn't slop, and is backed up by evidence.

Activity

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

    No labels
    No labels

    Type

    Projects

    • Status
      🚑 Needs Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions