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
Describe the bug
I use multipath with a per-path idle timeout (
default_path_max_idle_timeout). I open a second pathto 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. Butit is never freed: no
PathEvent::Discardedarrives,Connection::pathkeeps handing out a handlefor it and
Path::statuskeeps 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
serverandclientexamples with multipath turned onand one path opened to an address that never answers:
1a26a8b...HeikoBornholdt:noq:self-abandoned-path-repro
There is no
Discardedevent 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::Abandonedpromises:"This event will always be followed by
Self::Discardedafter some time".noq
Version: 1.3.0 @
1a26a8b06Platform(s)
Desktop:
lolwut
the issue being reported and wrote this as concisely and clearly
as they could. Taking full responsibility for the issue being
accurate.