dns name resolution failure is reported as internal error with traceback
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Bazaar |
Confirmed
|
Medium
|
Unassigned |
Bug Description
Any failure to resolve a DNS name results in bzr declaring it has hit an internal error, dumping a traceback and asking the user to report a bug. Bzr should catch the socket.gaierror exception and turn them into a less severe message as there is nothing bzr can do to resolve the situation in most cases.
This is somewhat similar to bug 186920, where a similar error is reported. However, that bug is about the gaierror exception being 'unexpected' in that case, whereas this report is suggesting that a gaierror should always be 'expected' even with a correctly setup but temporarily unavailable network.
For example, on a machine with the network cable unplugged:
% bzr co lp:tortoisebzr
bzr: ERROR: socket.gaierror: (11001, 'getaddrinfo failed')
Traceback (most recent call last):
File "bzrlib\
File "bzrlib\
...
File "xmlrpclib.pyo", line 1297, in send_content
File "httplib.pyo", line 860, in endheaders
File "httplib.pyo", line 732, in _send_output
File "httplib.pyo", line 699, in send
File "httplib.pyo", line 1134, in connect
File "<string>", line 1, in connect
gaierror: (11001, 'getaddrinfo failed')
bzr 1.7rc1 on python 2.5.2 (win32)
arguments: ['bzr', 'co', 'lp:tortoisebzr']
encoding: 'cp1252', fsenc: 'mbcs', lang: None
plugins:
bzrtools C:\Program Files\Bazaar\
launchpad C:\Program Files\Bazaar\
qbzr C:\Program Files\Bazaar\
svn C:\Program Files\Bazaar\
*** Bazaar has encountered an internal error.
Please report a bug at https:/
including this traceback, and a description of what you
were doing when the error occurred.
Changed in bzr: | |
status: | Triaged → Confirmed |
tags: | added: easy traceback |
tags: | added: check-for-breezy |
The similarity with bug #186920 is that in both cases the xmlrpc *uses* don't catch the connection related errors like we do for our http transports.
One way to address that would be to push down the stack many features (or error handling) that are currently implemented either in the http transport classes or the urllib2 wrappers. This is highly non-trivial :-/