refactor: minor cleanups in endpoint state

[Frando]

Description

This has a few minor cleanups without any functional changes in the endpoint state actor:

• Remove double handle upgrade
• Add helper function to_transport_addr on the relay mapped addr map
• Use hash map entry API instead of get and expect
• Use if let chains to remove a level of indentation

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/3626/docs/iroh/

Last updated: 2025-11-10T09:17:44Z

[flub]

Thanks, I think the path_remote helper can be a bit better still but good improvements!

[flub]

TIL you can combine let Some(x) bindings like this.

[Frando]

Yes it's really nice. It's quite new, added in 2024 edition.

[flub]

doc comment please.

I've gone back and forth on this. I used to have a helper for this at some point :) But I never like this kind of helper that just takes a bunch of random things by ref.

What about:

impl AddrMap<(RelayUrl, EndpointId), RelayMappedAddr> {
    /// Convert a mapped socket address to a transport addr.
    ///
    /// To map to a [`transports::Addr`] only the [`RelayMappedAddr`] needs to be able to be
    /// looked up.  So we can have this as a helper here.
    fn to_transport_addr(&self, sockaddr: SocketAddr) -> Option<transports::Addr> {
        MultipathMappedAddr::from(sockaddr).to_transport_addr(self)
    }
}

And probably MultipathMappedAddr::to_transport_addr should be removed and merged into this impl. It's just going to sow confusion over there.

[flub]

I've also always been a little on the fence on whether creating the AddrMap was a useful abstraction level. I'm not that sure.

I think now I'd try and make a single AddrMap struct (not trait) that contained both the mapped addrs in a single lock. It would be a much more natural place for this conversion to live. But anyway, we're here now and this isn't the most blocking thing.

[Frando]

sgtm! pushed this.