Opened 10 years ago
Closed 10 years ago
#22698 closed Bug (worksforme)
runserver does not exit when checks fail
Reported by: | Ben Davis | Owned by: | nobody |
---|---|---|---|
Component: | Uncategorized | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Normally I'd think if process of any kind has fatal errors, it should exit with a non-zero status code. If checks result in messages >= ERROR
, runserver will just hang there until you press Ctrl+C. This is due to the fact that checks are performed in inner_run()
as opposed to outer_run()
. Is there a reason why it's done this way, or is this a legitimate bug?
Note:
See TracTickets
for help on using tickets.
The check is done on the
inner_run()
because it's part of the reload mechanism; if you save a file, and an error is found, the inner loop stops, but the outer loop should attempt to reload when you save the file again. So - it's not a bug that the check is done ininner_run()
.The fact that runserver hangs *would* be a bug. If you save the affected file and fix the problem, runserver *should* reload. However, I haven't been able to reproduce the problem you describe. I tried creating a sample project with no errors on Django master (9a4bf72f), then I created a duplicate reverse accessor (by duplicating a foreign key), causing a
fields.E304
error. When I removed the foreign key, and re-saved the models.py file, runserver restarted as expected.Closing worksforme; if you can provide details of a specific error where you're seeing this problem, plus details of the Django version etc where you're seeing this, please reopen.