Opened 7 years ago

Closed 4 years ago

Last modified 3 years ago

#9589 closed Bug (fixed)

development server stops on SyntaxError or other Exceptions

Reported by: eibaan Owned by: nobody
Component: Core (Management commands) Version: 1.1
Severity: Normal Keywords:
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


It's a bit annoying that you have to manually restart the development server if you have a
SyntaxError, ImportError or NameError in a file because changes to that file are not detected.

This is caused - I think - by the fact that the autoreloader only watches files of successfully loaded modules.

I created a patch that catches those errors and adds fake modules to the system so that the autoreloader also checks for changes in those files. It's kind of hackish but it causes the reload after fixing the problems as wished for.

Attachments (3)

autoreload-r9410.patch (1.6 KB) - added by eibaan 7 years ago.
autoreload.diff (2.7 KB) - added by Glenn 7 years ago.
fixed 'exceptions.TypeError' object has no attribute 'filename'
autoreload-error_decorator-r11628.patch (2.2 KB) - added by berto 6 years ago.
Added decorator that checks for file errors and adds them to watch list.

Download all attachments as: .zip

Change History (19)

Changed 7 years ago by eibaan

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

This looks like a cure that's worse than the disease. After installing this fake module, you're now no longer running the correct code, so all sorts of unexpected things could happen, which will be quite misleading.

Given that the current error handling, although possibly a little annoying from time to time, is very explicit and doesn't result in incorrect behaviour, I prefer the current stuff. -1 from me on this patch.

comment:2 Changed 7 years ago by anonymous

I'd rather see it stay how it is now, though error messages should make it clear that any "no reverse exception" errors might be caused by errors while importing views.

comment:3 Changed 7 years ago by eibaan

mtredinnick, please notice that after an exception, no code is (or should) actually running anymore. The system stopps responding and only the background thread looking for file changes is still active. This is how the system behaves for all other exceptions already. I just added support for SyntaxError and ImportError. Fixing those problems in files is not detected by the background thread right now. I tried to add them. Faking modules seemed to be the easiest way to do so. Because I do not use "real" module names, there shouldn't be any strange side effects.

anonymous, this hasn't to do with "no reverse exception". My patch fixes the problem that after you made a syntax error in some file, the development server breaks down and has to be restarted manually.

comment:4 Changed 7 years ago by Glenn

This problem is pretty annoying, but I think this fix is a bit too much of a hack. I don't think it'll actually cause problems, but the attached patch should be a bit cleaner. It needs testing with jython_reloader.

Changed 7 years ago by Glenn

fixed 'exceptions.TypeError' object has no attribute 'filename'

comment:5 Changed 6 years ago by kmtracey

#11957 reported problems in this area with errors in files specifically. Not sure whether that is covered by the change proposed here.

comment:6 Changed 6 years ago by berto

I've created a patch that uses a decorator to solve this problem. When main() is called to start the reloader, the function passed in is wrapped in a decorator that currently catches IndentationError, NameError, SyntaxError, or TypeError. When one these exceptions is found, the file that caused the error is added to a list of watched files. This list is checked for modifications in addition to the files found in sys.modules.

Changed 6 years ago by berto

Added decorator that checks for file errors and adds them to watch list.

comment:7 Changed 6 years ago by berto

I have updated patch autoreload-error_decorator-r11628.patch, which now handles ImportError as well.

comment:8 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

I agree with Malcolm, so I'm marking this wontfix.

comment:9 Changed 6 years ago by Glenn

With who? This is very obviously a bug, and an annoying one. It makes no sense to wontfix this.

comment:10 Changed 6 years ago by Glenn

To respond more usefully (and less out of simple bewilderment), and assuming that "mtredinnick" is Malcolm (it would be helpful to not use names that make other people do research to follow a ticket; use the names being used in the tracker):

He responded to the initial patch, which had the bizarre behavior of modifying the global modules table (which should almost always be treated as read-only), and which nobody else liked either. That's why there are rewritten patches which eliminate that problem. I'm confused because you closed the bug agreeing that the first patch wasn't acceptable, despite the clean patches offered later by myself and berto.

comment:11 Changed 6 years ago by Glenn

  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Version changed from 1.0 to 1.1

No response in over a month, and my inquiry on django-dev was ignored, so I'm reopening this. The reason for closing it made no sense. If you reclose it, please do those of us who have spent time fixing this the courtesy of giving a meaningful explanation, and not just pointing to a reason that's six months irrelevant which multiple other people have long since corrected.

comment:12 Changed 5 years ago by gabrielhurley

  • Component changed from runserver to Core (Management commands)

comment:13 Changed 5 years ago by lukeplant

  • Severity set to Normal
  • Type set to Bug

comment:14 Changed 4 years ago by aaugustin

  • Easy pickings unset
  • Resolution set to duplicate
  • Status changed from reopened to closed
  • UI/UX unset

This problem was first reported in #8413. That ticket has a patch with a different technique.

comment:15 Changed 3 years ago by Ramiro Morales <cramm0@…>

  • Resolution changed from duplicate to fixed

In c2a6b2a43fb8f32cff078c823054e2e65f325464:

Fixed #9589 -- Made development web server more robust in the presence of a wider variety of code errors.

Thanks goes to contributor with Trac user 'berto' for the patch.

comment:16 Changed 3 years ago by Aymeric Augustin <aymeric.augustin@…>

In bbabfdcccee9ccd98fc140233dee748253bcb4a2:

Fixed #19485 -- Python 3 compatibility for c2a6b2a4.

Refs #9589.

Note: See TracTickets for help on using tickets.
Back to Top