Closed augustogoncalves closed 4 years ago
Sounds like a good idea. Perhaps the responses could be logged into some vscode logger whenever there's an issue? Or maybe we could somehow make them accessible from the UI, like with a "see the raw server response" button in the popup that shows up when there's an issue.
vscode logger sounds good, does it allow formating (JSON)? I would say in any case, success or error, just for debugging purposes.
I just realized that this may not be the best approach. The vscode extension uses the Forge Node.js SDK (currently it's using forge-server-utils but the same applies to forge-apis), and the purpose of an SDK is to hide away all the underlying HTTP requests and responses, turning them into "more useful" objects for the developer. So instead of showing raw HTTP responses from Forge, I should probably update/fix the SDK to show more useful information.
What problem exactly did you have with the POST job
request?
interesting...
this specific request started as the POST Job returns different body content depending on how the job was posted, and the developer was getting 4XX error and we couldn't understand why. To find it, we had to use Postman to see the response body
I see. When the Node.js SDK throws an exception (for example, when an API call wasn't authorized properly), the exception itself does include the HTTP response. So what I'm going to do is, whenever any of the Forge requests throws an exception and I show the error popup in vscode, I will add another button to show the raw HTTP response.
Done. Now, whenever there's an issue with a Forge API call, the error popup shows a Show Details
button which will open a new document with (pretty-formatted) raw HTTP response, incl. axios config, headers, status code, and body. The feature will be available with the next release of the extension.
For instance, see the header/body of a
POST Job
response. This can help debug problems if a translation is not starting.