[tahoe-lafs-trac-stream] [Tahoe-LAFS] #2859: introducer client uses cache even if it doesn't have to

[Tahoe-LAFS]

#2859: introducer client uses cache even if it doesn't have to
-------------------------+-----------------------
     Reporter:  dawuud   |      Owner:
         Type:  defect   |     Status:  new
     Priority:  normal   |  Milestone:  undecided
    Component:  unknown  |    Version:  1.12.0
   Resolution:           |   Keywords:
Launchpad Bug:           |
-------------------------+-----------------------

Comment (by warner):

 Huh. Looking at the code (`IntroducerClient.startService`), it looks like
 it will only read from the cache (`_load_announcements`) if a single
 `getReference` fails (via the errback to `connect_failed`). If that
 initial connection succeeds, there's no addCallback, so nothing will ever
 read from the cache.

 Specifically, it looks like we start a Reconnector (`tub.connectTo()`),
 then immediately start a normal `tub.getReference()` to the same FURL.
 If/when the Reconnector succeeds, we'll eventually overwrite the cache
 file. If/when the normal connector *fails*, we'll load the cache.

 Both of those are supposed to use the same connection attempt. I'm not
 sure which service will be `startService`d first. If the Tub is running
 before `IntroducerClient.startService` is called, then the `connectTo`
 should create the outbound connection, and the `getReference` should wait
 for it to complete (success or failure). If the Tub isn't running by that
 point, then both `connectTo` and `getReference` will be queued, and then
 maybe the order in which they trigger outbound connections will be
 unpredictable. But the second one is still supposed to *not* start a
 second independent connection: it should see that a connection is already
 in progress, and attach itself to wait for the results of that one.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/2859#comment:2>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage