Close connection if the last path is idle

[flub]

When the PathIdle timer fires we attempt to close the path. However this fails if it is the last open path. This means the connection will stay alive until the connection idle timer fires, if that is set. If that is not set the connection will never die.

I believe we should instead terminate the connection if the last path is idle. This makes the behaviour predictable and independent of how the connection idle timer is configured.

[matheus23]

If a user sets the idle timeout to None, then they expect the connection to never time out, right?

I guess you want to change this behavior to prefer the idle timeout for paths over the idle timeout for connections. I have a feeling that that would be surprising behavior.

[flub]

The connection and path idle timers work independent. If you configure no connection idle timeout but do configure a path idle timeout than the only logical behaviour is that you close the path after it becomes idle. If that is the last path that is equivalent to closing the connection. To me this is very logical, otherwise you are ignoring the path idle timeout. If this is confusing then let's document it.

[jost-s]

We hit this issue while upgrading to iroh 0.97 in kitsune2. Our test peer_is_set_unresponsive_after_connection_error simulates a peer going offline ungracefully (laptop-closed scenario — no CONNECTION_CLOSE frame, connection just goes silent). After the upgrade, accept_uni() on the surviving peer hangs indefinitely instead of returning an error.

The fix that unblocked us was calling endpoint.close() on drop, which sends an explicit CONNECTION_CLOSE. But that only works when the dropping side is in our control. For the real-world case where a remote peer disappears silently, the path idle timer fires, close_path_inner returns LastOpenPath, the error is just logged, and the connection continues alive.

+1 for closing the connection when the last path times out.

[matheus23]

This issue is somewhat different - we're discussing the connection closing earlier if the last path's idle timeout triggers, not fixing that the connection doesn't time out at all. I suspect you've set a connection idle timeout or kept it at the default 30s, and that doesn't trigger?

FWIW, we're aware of issues that show you can get stuck with connections becoming broken indefinitely without timing out - we're working on that, too.

[jost-s]

No, I'm referring to the case where the last path's idle timeout fires, but the connection isn't closed as a consequence. It seems consistent that a last path's idle timeout leads to closing the connection immediately, like a last path abandon does.

[matheus23]

Is the connection eventually closed in your case? You wrote

After the upgrade, accept_uni() on the surviving peer hangs indefinitely instead of returning an error.

which seems to indicate that it doesn't.

I just want to make sure that we're clear on what this issue is. This issue is not about a connection fully ignoring an idle timeout (which seems to be the issue you're experiencing).

Also in an effort to understand the exact problem: Do you have an idle timeout for your connection configured? (The default is 30s, so if you didn't change default settings, then yes you have.)

[jost-s]

Is the connection eventually closed in your case?

I guess it would be closed eventually due to the connection idle timeout. I observed this in an integration test when upgrading from v0.96 to v0.97. I don't have configured an idle timeout configured, it must be the default.

Sorry for the confusion, I've not seen this in production connections staying alive forever.

I believe that this is the line in question where the last path doesn't return an error but logs a warning, which results in the uni-directional channel not being closed until the connection times out:

noq/noq-proto/src/connection/mod.rs

Line 2399 in c2103a1

PathTimer::PathIdle => {