django faults when returning to admin-view after saving entry

[djangodev@…]

I am using the normal svn version of django as of today (2006-04-01, no joke ;)
and when saving an entry for one of my models (TemplateDomain) in the admin django
breaks into a non-prettyprinted stacktrace. I have so far only defined my models,
no code written/altered.

The model code:

class TemplateDomain (meta.Model):
    template = meta.ForeignKey(Template)
    domain = meta.ForeignKey(Domain)
    change_date = meta.IntegerField('Timestamp of last Change', null=True, editable=False)

    def __repr__(self):
        return self.name

    class META:
        db_table = 'template_domains'
        admin = meta.Admin(
                list_display = ('template','domain','change_date'),
            )

class Domain (meta.Model):
    name = meta.CharField('Domain Name', maxlength=255, db_index=True, unique=True)
    type = meta.CharField('Domain Type', maxlength=6, choices=DOMAIN_TYPES, editable=False, default='MASTER')
    master = meta.CharField('Supermaster Address', maxlength=255, blank=True, editable=False)
    last_check = meta.IntegerField('Timestamp of last check', null=True, editable=False)
    notified_serial = meta.IntegerField('Serial of last notify', null=True, editable=False)
    group = meta.ForeignKey(Group, null=True)
    account = meta.CharField('Supermaster Account', maxlength=255, blank=True, editable=False, help_text='Which supermaster brought us this domain?')

    def __repr__(self):
        return self.name

    class META:
        db_table = 'domains'
        admin = meta.Admin(
                list_display = ('name','type','master','last_check','notified_serial','group','account'),
                list_filter = ('name','type','group','account')
            )

class Template (meta.Model):
    name = meta.CharField('Template Name', maxlength=255)
    created_by = meta.ForeignKey(User)

    def __repr__(self):
        return self.name

    class META:
        db_table = 'templates'
        admin = meta.Admin(
                list_display = ('name','created_by'),
            )

the stacktrace:

Traceback (most recent call last):

  File "/usr/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 272, in run
    self.result = application(self.environ, self.start_response)

  File "/usr/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 615, in __call__
    return self.application(environ, start_response)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/wsgi.py", line 159, in __call__
    response = self.get_response(request.path, request)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py", line 109, in get_response
    return self.get_technical_error_response(request)

  File "/usr/lib/python2.4/site-packages/django/core/handlers/base.py", line 139, in get_technical_error_response
    return debug.technical_500_response(request, *sys.exc_info())

  File "/usr/lib/python2.4/site-packages/django/views/debug.py", line 126, in technical_500_response
    return HttpResponseServerError(t.render(c), mimetype='text/html')

  File "/usr/lib/python2.4/site-packages/django/core/template/__init__.py", line 146, in render
    return self.nodelist.render(context)

  File "/usr/lib/python2.4/site-packages/django/core/template/__init__.py", line 714, in render
    bits.append(self.render_node(node, context))

  File "/usr/lib/python2.4/site-packages/django/core/template/__init__.py", line 732, in render_node
    result = node.render(context)

  File "/usr/lib/python2.4/site-packages/django/core/template/defaulttags.py", line 112, in render
    nodelist.append(node.render(context))

  File "/usr/lib/python2.4/site-packages/django/core/template/defaulttags.py", line 174, in render
    return self.nodelist_true.render(context)

  File "/usr/lib/python2.4/site-packages/django/core/template/__init__.py", line 714, in render
    bits.append(self.render_node(node, context))

  File "/usr/lib/python2.4/site-packages/django/core/template/__init__.py", line 742, in render_node
    raise wrapped

TemplateSyntaxError: Caught an exception while rendering.

[Luke Plant]

What is the bug -- the fact that it is not pretty printed? Your TemplateDomain model has a fairly obvious error in repr(), which happens to be an important function in Django.

I think the problem is that when trying to pretty print the errors, it will use repr() (sometimes implicitly via str()) to print the current variables, so it gets the error again -- kind of catch 22 - how do you pretty print the contents of local variables if doing so throws more exceptions? I don't think magic removal has this problem though, so it might be possible to fix it fairly easily.

[jim-django@…]

This is solved in magic-removal? That's fantastic!

I think this issue deserves a higher severity than trivial though. The programming mistake here in the repr function may not affect the stability of django, but the fact that the template system hides the error and presents a non-obvious one in it's place can make debugging extremely difficult, especially as developers (for instance, me) get used to django's templates and metasystem.

The real bug is the swallowing of the original error, not the lack of pretty printing.

For templates in debug mode, calls to repr or str could, when they are explicit, be wrapped in try/except blocks, and could present "<%s>"%str(type(the_thing)) instead. I'll try this out when I'm in front of my emacs again.

[Luke Plant]

In magic-removal it appears that the admin/template system traps this kind of error, so you don't get a stacktrace at all. I guess you are right that it is more important than trivial, but I wouldn't put it higher than minor -- the defect only shows itself at all in the case of programmer error. I'm not sure if someone might backport the fix, so I won't close this just yet.

[Martin Maney]

I have to disagree that this is an error caused only by programmer error. I've tracked it down to an inconsistency in the type of "id" fields during Django's processing of the admin screen, at least under some circumstances. This is all using 0.91:

User.__repr__ entered: type of user_id is <type 'int'>
[04/Apr/2006 09:24:01] "GET /admin/poll/users/5/ HTTP/1.1" 200 5024
[04/Apr/2006 09:24:02] "GET /admin/jsi18n/ HTTP/1.1" 200 1019
User.__repr__ entered: type of user_id is <type 'str'>
User.__repr__ entered: type of user_id is <type 'str'>
Traceback (most recent call last):

The first call is during rendering of the User record edit screen (not shown is the preceeding call to the list-of-Users screen, which worked fine and had 'int' on every call). The latter is where it's going to redisplay the list-of-Users after saving the edited record. The error here is caused by the %d format spec that __repr__ uses for the id field (which is, in this case, an explicit AutoField).

I don't believe it is a [user] programmiong error to treat an integer field as an integer, yes?

Another oddity that I noticed as a side effect of this is that __repr__ is being called twice for every time it is actually needed to render the displayed page. That's visible on pages that render correctly, such as the list-of-Users page where there are eight calls for four items. I'm guessing that this is related to the fact that the exception that the first 'str' call above caused is being caught and ignored somewhere inside Django. Just observin'

I'm not changing any of the bug's properties because I don't know that this is (or is not) related to the original report here... and it does seem to me, too, that it's a separate bug that an error reporting page is failing in such an unhelpful way. I had to stumble across a hint about hacking Django's code in order to glean one skimpy clue (int expected) that let me eventually find this.

[Adrian Holovaty]

This is fixed in magic-removal, so I'm closing for now.