Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

500 Internal Server Error #31

Open
BoushZhou opened this issue Dec 4, 2018 · 1 comment
Open

500 Internal Server Error #31

BoushZhou opened this issue Dec 4, 2018 · 1 comment

Comments

@BoushZhou
Copy link

Internal Server Error
The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

@r-chris
Copy link

r-chris commented Jul 28, 2020

I realise this is a fairly old issue, but I have just made an interesting (for me) observation here. Before I get to my experience, allow me to say that you should provide a log of your pod (assuming this was deployed to Kubernetes) to determine the actual error that caused the "Error 500" reply. You could get that log by doing something like: kubectl logs -f azure-vote-front-USE_YOUR_POD_NAME_HERE which in my case showed this:

[2020-07-28 11:26:34,930] ERROR in app: Exception on / [GET]
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/local/lib/python3.6/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/local/lib/python3.6/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "./main.py", line 57, in index
    vote1 = r.get(button1).decode('utf-8')

Looking at the code here: https://github.com/Azure-Samples/azure-voting-app-redis/blob/master/azure-vote/azure-vote/main.py#L57 we can assume that for some reason r.get(button1) returns None.

Technically, this means that there is no entry in Redis with the key button1 (which equals "Cats" in the default configuration: https://github.com/Azure-Samples/azure-voting-app-redis/blob/master/azure-vote/azure-vote/config_file.cfg#L3)

Why would there be no entry in Redis? After all this line if not r.get(button1): r.set(button1,0) initiallized those values with something: https://github.com/Azure-Samples/azure-voting-app-redis/blob/master/azure-vote/azure-vote/main.py#L48

Turns out - in my case - I had applied the azure-vote-all-in-one-redis.yaml file, then made a change to the azure-vote-back and applied the deployment again. Since I only edited the azure-vote-back (Redis service), the front-end app (azure-vote-front) did not re-initialize, but kept running and assuming that it had in fact already initialized those Redis keys!

Therefore, the underlying issue here is, that you should either use persistent Redis storage if you want to rely upon some pre-initialized values or you should to improve the error handling in those situation. Now I realize this is only a sample app without those considerations, but it would be a good follow up for a tutorial to explain why (and how) persistent storage is added for a database backend.

You could either restart the azure-vote-front pod, which will automatically re-initialize those Redis values or you could manually set them yourself (for example through an interactive shell).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants