This topic was automatically generated from Slack. You can find the original thread here.
David Watson : Is there any way to see the REQUEST for a successful Axios?
I have 2 Workflows linking to the Short.io API and one is working fine , but the other is failing with a 401 error. So I wanted to compare the REQUESTs to see any differences, because the one that is failing looks fine, but there obviously must be something wrong in my Authorisation.
I can find the REQUEST of the Workflow that is failing because it gives me Debug info. But I can’t see the REQUEST of the Workflow that succeeds because there is no Debug info
Danny Roosevelt : Hey , I ran into this the other day during my own debugging and had the exact same thought! I created this super simple workflow that might be helpful for you to add some debugging: https://pipedream.com/@droosevelt/axios-debugging-p_PACJ1aG/edit
David Watson : Yes that’s basically what workflow does but for some reason when you have a success at Short.io that header info is NOT included in the response.
You DO get the header info on the response of an error at Short.io though
David Watson : I re-did this completely from scratch and got it working. I must have done something wrong in my authorisation of the one that didn’t work, although I was unable to track down exactly what it was.
David Watson : If you look at “List Domains via Short.io API” and look at the step “steps.short” for one of the events there, you will see that the REQUEST does not get returned in the RESPONSE. Maybe it’s just a quirk of Short.io
Dylan Sather (Pipedream) : Hi David, the issue is that you’re still using the @pipedreamhq/platform version of axios, which doesn’t return the full axios response object when the request succeeds. If you take a look at Danny’s workflow, you’ll see that he’s using normal axios . The code in that workflow should target the use case you want: show the full response object (which includes all the request details) on the success or error case.
Dylan Sather (Pipedream) : We’ve found that the code in the default step is what works best for most users (i.e. most uses do not need to see the details of the request on successful requests), which is why we implement it that way
David Watson : OK, understand … I’ll just use the code from the default step most of the time, and remember that if I need extra debugging facilities to change it over to the alternative that you mentioned, and which @U02A06JPKEH had in his example.
Dylan Sather (Pipedream) : for sure. I can definitely see this as a future UI option on actions, as well (e.g. “Enable debugging”, which would give you the full request data).