Forums

server 500 response to external FitBit request

I've just deployed an app on PythonAnywhere (my first time). I have run into an issue which I didn't have when running the app on my local development machine.

My app is meant to listen to notifications from FitBit which are sent to a pre-defined 'endpoint' - a url that my app picks up on (e.g., 'http://myApp.pythonanywhere.com/fitbit_notifications'). To start receiving the updates, I need to verify the endpoint first. For that, FitBit sends two GET requests to the endpoint containing a verification code -- one correct, one not, -- and I have to respond with 204 or 404 status status codes if the verification code is matching or not respectively.

This setup was working fine until I deployed the app on PA. The problem is that when FitBit sends the verification request, the PA server responds with 500 to the first request and 499 to the second. As far as I can tell, everything should work fine.

Here is what it looks like in the 'error.log':

"GET /fitbit_notifications/?verify=[code] HTTP/1.1" 500 38 "-" "python-requests/2.11.0" "95.146.221.231"

I am a bit clueless as to why it might be so and how to go about debugging this. Any help would be greatly appreciated!

Thanks!

Davis

Your first step to debuggingis probably to see what the responses that you're sending to fitbit are. Hit the urls on your web app as fitbit would and see what you're sending them. The 500 should be generating an exception trace in your error log that you can use to determine what's causing it.

Thanks!

Fixed it this morning in five minutes. I think I had a serious case of tunnel vision last night after long hours of coding.

It turns out I had left in some erroneous code in the view that was responding to the request, but was convinced that the problem lied elsewhere and looked in the wrong places.

Thanks!

Fixed it this morning in five minutes. I think I had a serious case of tunnel vision last night after long hours of coding.

It turns out I had left in some erroneous code in the view that was responding to the request, but was convinced that the problem lied elsewhere and looked in the wrong places.

Excellent.