dns name resolution failure is reported as internal error with traceback

Bug #270329 reported by Mark Hammond
2
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\commands.pyo", line 857, in run_bzr_catch_errors
  File "bzrlib\commands.pyo", line 797, in run_bzr
...
  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\plugins\bzrtools [1.8.0]
  launchpad C:\Program Files\Bazaar\plugins\launchpad [unknown]
  qbzr C:\Program Files\Bazaar\plugins\qbzr [0.9.4dev0]
  svn C:\Program Files\Bazaar\plugins\svn [0.4.12dev0]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

Revision history for this message
Vincent Ladeuil (vila) wrote :

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 :-/

Changed in bzr:
importance: Undecided → Medium
status: New → Triaged
Martin Pool (mbp)
Changed in bzr:
status: Triaged → Confirmed
Martin Pool (mbp)
tags: added: easy traceback
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.