refactor(dcutr): remove ActionBuilder.

[jxs]

Description

addresses #3299

Notes

Links to any relevant issues

Open Questions

We are now getting the observed_addresses at different places, i.e. previously we had PollParameters on poll with what I assume would be the list of updated external_addresses that would be then used to calculate the list of observed_addresses. Now we get the list of observed_addresses from the ExternalAddrs which is updated on NewExternalAddr, but will it make a difference that it might be updated when an Event has already been added to queued_events?

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[mxinden]

We are now getting the observed_addresses at different places, i.e. previously we had PollParameters on poll with what I assume would be the list of updated external_addresses that would be then used to calculate the list of observed_addresses. Now we get the list of observed_addresses from the ExternalAddrs which is updated on NewExternalAddr, but will it make a difference that it might be updated when an Event has already been added to queued_events?

Sharp thinking!

I would expect NewExternalAddr to be triggered somewhere on the order of magnitude of <100 over the lifetime of a node, with a "burst" at start-up time.

I would expect the time between an on_connection_event (receiving the external address request from the ConnectionHandler) and a poll (returning the external addresses via the Swarm to the ConnectionHandler) to be below the order of ms.

With the above in mind, I would deem the probability that we are missing an external address very low, where missing an address does not even mean a failed direct-connection-upgrade in the first place. Also note that a failed direct-connection-upgrade is retried 2 times.

Does the above reasoning make sense?

[jxs]

We are now getting the observed_addresses at different places, i.e. previously we had PollParameters on poll with what I assume would be the list of updated external_addresses that would be then used to calculate the list of observed_addresses. Now we get the list of observed_addresses from the ExternalAddrs which is updated on NewExternalAddr, but will it make a difference that it might be updated when an Event has already been added to queued_events?

Sharp thinking!

I would expect NewExternalAddr to be triggered somewhere on the order of magnitude of <100 over the lifetime of a node, with a "burst" at start-up time.

I would expect the time between an on_connection_event (receiving the external address request from the ConnectionHandler) and a poll (returning the external addresses via the Swarm to the ConnectionHandler) to be below the order of ms.

With the above in mind, I would deem the probability that we are missing an external address very low, where missing an address does not even mean a failed direct-connection-upgrade in the first place. Also note that a failed direct-connection-upgrade is retried 2 times.

Does the above reasoning make sense?

yes! Thanks for the explanation Max. 👍

[mxinden]

Small suggestion. Otherwise this looks good to me.

[thomaseizinger]

Nice to see this simplification, well spotted @mxinden !

Gives me confidence that #3153 was a good call!

[thomaseizinger]

Whoops, wrong button :)