2023-11-21
Goal
To fix the 500 Response Error.
Notes
Fixing the 500 Response Error
This damn response error is kicking my butt. It's difficult to debug and a very vague error code that could indicate any number of errors with the Blog App. I'm gonna kick things off today by restarting my computer.
I ended up running into an error with the SSL Certificate where it was automatically redirecting me to an https
route in development even though the link was to http
. I ended up using the feature of the chrome browser's Developer Tools in the Developer Tools Network Tab to disable the Cache. Now it works! This should also help me get rid of caching issues in the future, however it might also be useful to keep the cache enabled because it might be something that other users are also going to have to work with.
Either way I could get back to fixing the 500 response code error. What's interesting about it is it effects both the Blog App and the About App. Typically I encounter this problem due to difficulties with migrations / databases however since I know the About page has no data to keep track of I know that it is a different problem.
I decided to use the following to log errors:
### LOGGING
# Get more detailed logs in production
LOGGING = {
'version': 1,
'disable_existing_loggers': False,
'handlers': {
'console': {
'class': 'logging.StreamHandler',
},
},
'loggers': {
'django': {
'handlers': ['console'],
'level': os.getenv('DJANGO_LOG_LEVEL', 'ERROR'),
},
# You can add more loggers for your own application or other Django modules
},
}
where the level
is set to INFO
now in my Environment Variables on my local machine. I decided to add this environment variable to my Heroku logs as DEBUG
as well via the Heroku CLI:
heroku config:set DJANGO_LOG_LEVEL=INFO -a dimmin
Then verified that it was set via
heroku config -a dimmin
.
This is one that I can always change later (maybe after I figure out more about this 500 error), but I'll leave it as the verbose DEBUG
setting for now. As far as I am aware, this doesn't cause a security concern because I have to log into my account to access these logs via my Heroku CLI, but I'll have to remain vigilant against potential hazards here.
Funnily enough, using Git Reset to a slightly younger branch and pushing those changes to Heroku actually fixed the problem. Still have no idea what the problem was but now it works... Yay! Now I can keep doing whatever I was doing before... adding timezone functionality to the Taskmaster App.
Taskmaster
Looks like I reverted to a previous version of the site before the taskmaster UI was complete... Whoops. The weird thing about it is I can see the HTML, CSS, and JS are the same as they were before but for some reason it doesn't look the way it did before. When I go into incognito mode in my local development environment I can see the correct layout so I know that the code is working. For some reason this exact same code pushed to Production isn't showing the same UI.
Results
- Fixed 500 error! Blog App and About App are now accessible on the DIMMiN App
- Learned about Django's logging settings and created an environment variable that could adjust how verbose their outputs are
- Rolled back code, will have to restart implementation of timezone functionality for the Taskmaster App
Next Time
- Figure out how to update the taskmaster app, currently looks like it isn't loading in the correct CSS and Javascript files even though I can see those correct files on GitHub.