id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
129	zero-length location hints cause getReference() to fail synchronously	Brian Warner		"Zooko noticed an exception that highlighted an unexpected code path in Tub.getReference():

{{{
File ""/home/zooko/playground/allmydata/tahoe/trunk/support/lib/python2.6/site-packages/foolscap-0.4.1-py2.6.egg/foolscap/negotiate.py"", line 1366, in connectToAll
    self.checkForFailure()
File ""/home/zooko/playground/allmydata/tahoe/trunk/support/lib/python2.6/site-packages/foolscap-0.4.1-py2.6.egg/foolscap/negotiate.py"", line 1440, in checkForFailure
    if (self.failureReason.check(RemoteNegotiationError) and
exceptions.AttributeError: 'NoneType' object has no attribute 'check'
}}}

I think here's what happened:

 * somebody set their Tahoe node to use tub.location=""""
 * the Introducer published this FURL along with a bunch of others in a
   single announcement
 * Zooko's client received that announcement and started connectors to each
   of them
 * when it hit the zero-length location hint, we fell through the loop in
   {{{TubConnector.connectToAll}}} and landed in {{{checkForFailure}}}
   without ever actually having seen a failure, so {{{self.failureReason}}}
   was still None
 * the synchronous exception bypassed the rest of the each-announcement loop,
   causing his client to not try to connect to anybody else

What should happen is that the call to Tub.getReference() should return
defer.fail (i.e. a Deferred that's already in the errback state). We can't
connect to a Tub that has no location hints (although they might have already
connected to us), but the failure should be eventual, not synchronous.
"	defect	closed	major	0.4.2	negotiation	0.4.1	fixed