flake8
passed.
JSHint
passed.
Handle PRODUCTION not being defined.
Review Request #13927 — Created June 3, 2024 and submitted
We introduced the new PRODUCTION setting in order to add a separation
between things which enable debug logging, and things which should
always be enabled (or disabled) in production vs. in the devserver. This
was done because a lot of server admins like to set DEBUG to True if
they're having some issue, and this would often cause their whole system
to break.In Djblets, we can't guarantee that PRODUCTION will exist in the
settings object. This change makes it so we fall back to the DEBUG
setting if it's not present.
- Ran unit tests.
- Tried removing PRODUCTION from settings and saw that these things
still worked.
| Summary | ID |
|---|---|
| b48de73af4fa8d49faa8af5ebd6e5193e0f9838b |
| Description | From | Last Updated |
|---|---|---|
|
I think this conditional is wrong. The old conditional would log instead of outright break in production. However, the conditional … |
 chipx86
|
-
-
I think this conditional is wrong.
The old conditional would log instead of outright break in production. However, the conditional in this change does the opposite. It only logs if:
DEBUG = TruePRODUCTION = FalsePRODUCTIONis not defined
It's that second condition that regresses this logic.
The logic as we had it was correct. In fact, originally this had been broken, and we had fixed it. We only want to raise an exception in development or debug modes.
I believe we want:
if (settings.DEBUG or getattr(settings, 'PRODUCTION', True)): ...Plus, in all other cases, if
DEBUGisFalse,PRODUCTIONwould default toTrue. If we were to centralize thePRODUCTIONcalculation at some point, the code in this change would then regress again.The tests can then be reverted once this is fixed.
