Closed
Bug 979294
Opened 10 years ago
Closed 8 years ago
balrog index page throws exception when db is empty
Categories
(Release Engineering Graveyard :: Applications: Balrog (backend), defect, P3)
Release Engineering Graveyard
Applications: Balrog (backend)
x86_64
Linux
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: bhearsum, Unassigned)
Details
Massimo discovered this in bug 938132: (In reply to Massimo Gervasini [:mgerva] from comment #6) > Hi Ben, > > I am testing the code locally. There's only a problem I have found: after > deleting a rule, if you click on the "AUS3 Admin" link it shows the > following message: > > Recent changes > Loading recent changes ... > > but there is nothing to show because prev_change is None. > > From logs: > auslib/admin/views/index.py line 146, in decorateChanges > for x in prev_change > TypeError: 'NoneType' object is not iterable
Reporter | ||
Comment 1•10 years ago
|
||
I can't reproduce this anymore, and it's such an edge case that it's probably not worth addressing.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Reporter | ||
Comment 2•10 years ago
|
||
And now I just hit this on aus4-admin-dev...
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
Reporter | ||
Comment 3•10 years ago
|
||
Possibly not related to an empty db though. Full traceback is: File "flask/app.py", line 1292, in wsgi_app response = self.full_dispatch_request() File "flask/app.py", line 1062, in full_dispatch_request rv = self.handle_user_exception(e) File "flask/app.py", line 1060, in full_dispatch_request rv = self.dispatch_request() File "flask/app.py", line 1047, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "flask/views.py", line 56, in view return self.dispatch_request(*args, **kwargs) File "flask/views.py", line 112, in dispatch_request return meth(*args, **kwargs) File "auslib/admin/views/index.py", line 113, in get self.decorateChanges(recent_changes, changes, other_values) File "auslib/admin/views/index.py", line 146, in decorateChanges for x in prev_change But the db is definitely not empty. Perhaps this is associated with no changes being made recently instead?
Reporter | ||
Updated•10 years ago
|
Priority: -- → P3
Reporter | ||
Comment 4•8 years ago
|
||
I don't think this is an issue anymore - there's no views that look for history outside of the context of a specific object. AFAICT, this only happened on the old "recent changes" splash page, which is dead.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 8 years ago
Resolution: --- → INVALID
Updated•4 years ago
|
Product: Release Engineering → Release Engineering Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•