Launchpad itself

Trac status import code doesn't handle non-existent bug trackers well

Bug #175417 reported by Graham Binns on 2007-12-10

Affects		Status	Importance	Assigned to	Milestone
	Launchpad itself	Fix Released	Low	Graham Binns

Bug Description

If a bug watch is registered against a Trac instance that doesn't actually exist then trying to update that watch raises an error that isn't handled correctly at the ExternalBugTracker level.

See original description

Tags:

Revision history for this message

Graham Binns (gmb) wrote on 2007-12-10:

trac-error.txt Edit (1.0 KiB, text/plain)

The bug watch in bug 63529 against http://opendict.inhangar.com/ticket/2 is a case in point. The remote bug tracker doesn't exist (showing only an advertising page) and it causes the attached error when checkwatches.py runs.

Changed in malone:
importance:	Undecided → Low
status:	New → Confirmed
description:	updated

Graham Binns (gmb) on 2008-05-02

Changed in malone:
assignee:	nobody → gmb
milestone:	none → 1.2.5
status:	Confirmed → In Progress

Revision history for this message

Graham Binns (gmb) wrote on 2008-05-02:

The correct way to behave here is to raise an UnparseableBugData error instead of a KeyError. This specific problem occurs because although the remote host exists, it isn't behaving like a Trac instance. If it didn't exist at all we would get a BugTrackerConnectError.

Once this is fixed we'll still see errors in the logs from trackers of this nature (see bug 67480). Ideally we should be able to disable these bugtrackers until they are pointed at the correct location (bug 225829).

Revision history for this message

Graham Binns (gmb) wrote on 2008-05-09:

Landed in r6251.