Test suite: improve Chutney network bootstrap with launch phases

anonym
2025-07-09T09:07:49Z

Starting all Tor nodes in a network at the same time has various races, for instance [Tor (legacy) \#33582](https://gitlab.torproject.org/legacy/trac/-/issues/33582) which moved to [Tor \#33582](https://gitlab.torproject.org/tpo/core/tor...

Starting all Tor nodes in a network at the same time has various races, for instance Tor (legacy) #33582 which moved to Tor #33582 talks about:

there's a race condition when bridges try to publish their descriptor to the bridge authority:

bridges try to publish their descriptors before bootstrapping

but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority

Bridges will eventually try to publish their descriptors again, when they become dirty.

And that takes time, slowing down our test suite runs. And I think we sometimes see issues with relays racing against the authorities and getting in some state where they their bootstrap is delayed some minutes.

This isn't very relevant for the real Tor network since it (hopefully!) never will have to start from scratch again, so they solved this in Chutney by introducing "launch phases", so you could do stuff like:

 BridgeObfs4 = Node(
     tag="obfs4",
     bridge=1,
     relay=1,
-    torrc="bridge-obfs4.tmpl"
+    torrc="bridge-obfs4.tmpl",
+    launch_phase=2
 )

which means that BridgeObfs4 nodes will start after all nodes with lower launch_phase (default is 1) have bootstrapped and are ready. I see several improvements:

This should give us a cleaner solution to #20493 (closed) than fb5bce56 and probably faster too since we avoid the bridge race mentioned above. I find it annoying that the wait added by fb5bce56 usually add an extra 60 seconds or so of a new test suite run to actually get started (not for full runs, but definitely when repeatedly running a scenario using the network during development).

Maybe we can improve the whole networks' bootstrapping by giving authorities launch_phase=1, guard/middle/exit nodes launch_phase=2, bridges and the single Tor client launch_phase=3?

Implementing this will require a bit of work on our side, though, because Chutney isn't handling the start and ordering of all launch phases automatically, you have to invoke chutney configure/start/wait_for_bootstrap with LAUNCH_PHASE=N in the environment for all launch phases 1, 2, ... (see tools/bootstrap-network.sh in a recent Chutney Git checkout). If upstream thinks it would be a good idea if chutney handled this itself, then that is an alternative too.