There is a mindset will guide you when debugging, this attempts to describe it, and then identify concrete ways that it led to decisions as a student and I performed a debugging.
We were working in a Rails application that was authenticating with github, and then getting a 401 error when asking for our repositories after getting the token.
When I debug, I tend to look for several things. In this case, I've identified 3(ish) things that I did during the debugging:
- Get good feedback
- Remove complexity / isolate the problem
- Verify assumptions
Getting good feedback: We switched to curl so that we could see the actual HTTP response, and not have to make sense of Faraday's results.
Removing complexity: By taking Faraday, and even Ruby out of the picture, we can isolate where the problem is happening.
- If it had worked with curl, we would know the problem was how we were talking to Faraday.
- Since we still hit the 401, we knew we could ignore Faraday, and focus on how we were talking to Github.
Removing complexity: The pry in the controller allowed us to see what comes back from the api, without having to deal with ActiveRecord, or the database.
Getting good feedback: It might have turned out that there was something interesting in that response's configuration, beyond just the token.
Verifying assumptions: We know what we want to send, and we know what we think we're sending, we checked that these match by sending our request to a local server that prints out everything it sees. This allowed us to see our request.
nc -l 3001 to start the server.
curl -i 'http://localhost:3001/api.github.com/users/repositories' -H 'Accept: 123123123123123 USER-TOKEN'
to send the request.
The -i flag to curl allows us to see the entire request that github sends back,
so that we can see things like headers and response code.
Removing complexity: We know what the query param should look like, by doing this, we remove the possibility that we're misunderstanding what the header should look like.
Some things that could have been wrong:
- The token might not be correct
- This might not be what the token is for
- We might not be using it correctly
Isolating the issue: If it had worked elsewhere, then we'd know the token is correct, and that this is what it is for.
Getting good feedback: Then we could compare how we used it elsewhere, to identify how our current use was wrong
Verifying information: We realized that one possible explanation
was that our auth was correct, but we were requesting access to something
that we weren't allowed to access. So we verified this by removing the complexity
of the default type=all, asking instead for type=public.
This turned out to be the piece, as we saw when it printed all the data that we had requested.
Now that we understand the problem is that we're implicitly asking for access to private repos, we can take that information, and figure out how to reincorporate it into our context. Perhaps that means that our request only asks for the public data, or perhaps it means that our app asks for permission to access private repos.
Whatever the solution, we can now address that piece, because we actually understand the problem :)