fix: 0rtt flakes

[Arqu]

Description

So rough description of what was happening:

• the errors got swallowed but nuked the loop so it failed silently - fixed that
• the 0rtt tries connecting on the new port/addr but still prefers the old path so needs to wait out for the path invalidation to do it's job before it continues to work

Being slow enough made it sometimes pass. Locally now tests pass ~instantly vs 15 seconds or so after the fix to gracefully handle errors.

I'm unsure if this is safe at all, like handling path updates from other angles or partial updates etc.
If it turns out too risky, we can drop the path invalidation changes and just keep the graceful error handling. Tests will pass.

Breaking Changes

Notes & open questions

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.
  • List all breaking changes in the above "Breaking Changes" section.
  • Open an issue or PR on any number0 repos that are affected by this breaking change. Give guidance on how the updates should be handled or do the actual updates themselves. The major ones are:
    • quic-rpc
    • iroh-gossip
    • iroh-blobs
    • dumbpipe
    • sendme

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/iroh/pr/3496/docs/iroh/

Last updated: 2025-10-07T06:43:29Z

[github-actions]

Netsim report & logs for this PR have been generated and is available at: LOGS
This report will remain available for 3 days.

Last updated for commit: 43bc650

[dignifiedquire]

@Frando @flub can you look at this please, I believe the two of you looked at this before

[flub]

I'm not sure. On a cursory look I think we get NodeAddr for other reasons, e.g. when a user dials with a NodeAddr. And that could be totally out of date and other info could be fresher.

In the multipath branch I currently send the initial packets to all known remotes. So that would mean whatever the working path, it should find it. I think it might need some kind of expiry of paths at some point, but wasn't going to do that immediately.

I've honestly been avoiding thinking too much about how to robustly solve these kind of issues in the current version, because it just slows down multipath work... but if others agree there's an improvement here that's fine.

[Frando]

I'm also unsure, I'll have to dig in a bit more to find out if this could have unintended side effects (ie falsely invalidating good paths).

[Arqu]

So what's our path forward here, should I drop the path update and just make sure we survive errors in the loop? That's a "good enough" fix for the flaky tests for now. Just not a proper fix for the underlying issue.

[dignifiedquire]

So what's our path forward here, should I drop the path update and just make sure we survive errors in the loop?

Yeah lets do that, and file an issue, with the details that you discovered. And then we reexamine this once multipath has landed

[Arqu]

Reverted the path invalidation logic and followed up with an issue #3504