It seems like we have 2 kind of issues:
- code broke runserver,
- network broke runserver.
In the first case, runserver waits for a code reload event which is perfect
;)
In the second case, runserver also waits for a code reload event, which is
not very intuitive after fixing a network error.
So if we want to handle both case, we indeed need to detect if an error is
caused by code or networking, which is defined by CACHES, DATABASES and
CHANNEL_LAYERS.
Perhaps we could add a special attribute to the exception, so
DatabaseWrapper.get_new_connection()'s call of:
connection = Database.connect(**conn_params)
Would become something like:
try:
connection = Database.connect(**conn_params)
except Exception as e:
e.network_error = True
raise
Another way would be to inspect exc info or have a pre-defined list of
exceptions that are to be considered as network error, which involves
referencing to exceptions potentially defined by other packages such as
redis.
While that may seem a lot for runserver, I've restrained myself from
talking about what this could look like in production so far in the
discussion, but I feel like even production deployment could somehow
benefit from this at some point, so that might be worth the effort after
all.
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAC6Op1-xvvwDHpo-Qzc2ycQQ6q1H7NO5FFJbZQqzphOGfPrZvA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
