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

Issues with failed HTTP calls #333

Open
alekdavisintel opened this issue Oct 15, 2024 · 0 comments
Open

Issues with failed HTTP calls #333

alekdavisintel opened this issue Oct 15, 2024 · 0 comments

Comments

@alekdavisintel
Copy link

alekdavisintel commented Oct 15, 2024

I was testing a local REST API (running on localhost) and accidentally defined a wrong port in the base URL. While I was beating my head over the wall trying to figure out what was broken (took me several hours), I noticed (once I figured it out) a couple of issues that made my troubleshooting more complex than it should've been, so I'm wondering if there is a chance to get them work better.

Scenario:

There is one test that requires authentication (OAuth2 in my case), the test's endpoint URL has a part that contains a variable, and the URL has a bad port number (but there may be many possible issues with failed HTTP calls).

OAuth call output

The OAuth call output has some extra information that is really hard to read and gives an impression that the auth call failed, e.g.

=== PRE-cleanup: GET sample ===

POST https://login.microsoftonline.com/xxx/oauth2/v2.0/token
=> 200 (334 ms, 2.07 kB)ERROR {"url":"https://localhost:7099/samples/$name(TestSample)","protocol":"HTTP","method":"GET","headers":{"Authorization":"Bearer eyJ0eXAiyturuytru43554GDFGFSiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1jN2wzSXo5M2c3dXdnTmVFbW13X1dZR1BrbyIsImtpZCI6Ik1jN2wzSXo5M2c3dXdnTmVFbW13X1dZR1BrbyJ9.eyJhdWQiOiJhcGk6Ly82ZWUyNjkxZi1lMDE3LTQyNTgtOGM2Mi0zNDA3NTIadgsgasdfgasdfEdargeDUiLCJpc3MiOiJodHRwczovL3N0cy53aW5kb3dzLm5ldC85ODg5ZTQxMS00MzgzLTQ1MDAtOGMyYS1lOGYwOTU0MzhmNGYvIiwiaWF0IjoxNzI4OTUwMDY4LCJuYmYiOjE3Mjg5NTAwNjgsImV4cCI6MTcyODk1Mzk2OCwiYWlvIjoiazJCZ1lGQmZjM2hsZ21QR2JmSFRSbi9hTmQyNUFRPT0iLCJhcHBpZCI6IjM3YTczYzc4LWU0ZWUtNDYzYy1hNzU5LWVmMzJkOGNkYzA5ZSIsImFwcGlkYWNyIjoiMSIsImlkcCI6Imh0dHBzOi8vc3RzLndpbmRvd3MubmV0Lzk4ODllNDExLTQzODMtNDUwMC04YzJhLWU4ZjA5NTQzOGY0Zi8iLCJvaWQiOiJlOGVmZjA4MC1jN2Y5LTQ4YjUtODVjZS1iOThjZTY0NjQzMzgiLCJyaCI6IjAuQVJnQUVlHJGJgjhg7478JGJgjhgjjUt1andsVU9QVHg5cDRtNFg0RmhDakdJMEIxSlNYVVVZQUFBLiIsInJvbGVzIjpbImFwaS5hbGwiXSwic3ViIjoiZThlZmYwODAtYzdmOS00OGI1LTg1Y2UtYjk4Y2U2NDY0MzM4IiwidGlkIjoiOTg4OWU0MTEtNDM4My00NTAwLThjMmEtZThmMDk1NDM4ZjRmIiwidXRpIjoiQVFULWpWNUZYa3kyRndLTVd3VVVBQSIsInZlciI6IjEuMCJ9.egQCTSAczQzaAiB_QQQQvIWJK8Ngac3t7orSRlFxGvo5i8WsJVCIXo69eZXI6IxNIanLgUiyRShdsR5rJo62lWbdClDqtge6UjK0jFTJzbi9yew46jwbySdrAm0dacSAHERG9EIgYLNQK6dDfFBnTCvb94695m_srafDQCQ2gjmm1otaojYk5ugEew-0gGeBYVAVGopPHQ5RaCEgT0FXDYF4d_ApfD4-Kr3UqKxHRmngz8e0OcdD7bHi2jBH6kLqljF9NAYxLUsweyt7mBVfsk3EmJLSKVNLL4nSrCONLBi7q2epayHUMc15sN52Swi1WzRP2IgOCA1ipsvF4Uv82Q","Accept":"*/*","User-Agent":"httpyac"},"options":{"cookieJar":{"version":"[email protected]","storeType":"uE","rejectPublicSuffixes":false,"enableLooseMode":false,"allowSpecialUseDomain":true,"prefixSecurity":"silent","cookies":[]},"hooks":{"beforeRedirect":[null],"beforeRequest":[null]}},"proxy":""}

I'm not sure what the intention to include extra variables is, but if the OAuth call was successful, I would expect the standard OAuth response to be displayed.

Error message in red

The error message inside of the red outline in the code and test results just shows the red circle with the name of the test, so it's not clear what the actual problem is (it's nice that the red circle looks differently from the red cross displayed for failed test).
image

Variable expansion in output

The HTTP call line in the TEST RESULTS panel does not substitute variables with the values, so in my case it showed something like:

=== PRE-cleanup: GET APPROVER workgroup ===
GET /samples/$name({{sampleName}})

I spent a couple of hours trying to figure out why the variable substitution did not work until I realized that it was just the "feature" (in fact, the OAuth call output above, the endpoint URL shows with variable expansion).

Error message format

The error message following the HTTP call line in the TEST RESULTS panel, is really long and it cannot be wrapped up, so in some cases, you cannot even read it. Also, when I try to resize the panel using the vertical divider between the test results output and the tree view on the right side of test results, when I moved the divider to the left over the error message, the covered part of the error message got erased (and it did not get restored), so the UI behavior is a bit weird.
image

Error information

Here is what the error message said in my case:

✖ Test failed (RequestError: at ClientRequest.<anonymous> (c:\Users\myusername\.vscode\extensions\anweber.vscode-httpyac-6.15.1\dist\extension.js:148:14752) - Object.onceWrapper (node:events:634:26)

Additional information in the http - Request window showed the call stack:

RequestError: 
	at ClientRequest.<anonymous> (c:\Users\myusername\.vscode\extensions\anweber.vscode-httpyac-6.15.1\dist\extension.js:148:14752)
	at Object.onceWrapper (node:events:634:26)
	at ClientRequest.emit (node:events:531:35)
	at a.emit (c:\Users\myusername\.vscode\extensions\anweber.vscode-httpyac-6.15.1\dist\extension.js:143:31169)
	at TLSSocket.socketErrorListener (node:_http_client:500:9)
	at TLSSocket.emit (node:events:519:28)
	at emitErrorNT (node:internal/streams/destroy:169:8)
	at emitErrorCloseNT (node:internal/streams/destroy:128:3)
	at process.processTicksAndRejections (node:internal/process/task_queues:82:21)AggregateError: 
	at internalConnectMultiple (node:net:1118:18)
	at afterConnectMultiple (node:net:1685:7)

This could be useful for the developer, but for a user, it's not very meaningful. I don't know if this is a Node.js limitation (I don't do Node.js), but shouldn't there be an actual error message indicating the problem (e.g. no service listening on the specified port)? I just finished writing C# code that makes external calls, and for the handful of expected cases (bad DNS/port/path/method/etc) it was not hard to get the meaningful error message. As I said, maybe it's a Node.js limitation, but if the errors contained just the actual reason of the failure, it would be a lot more helpful.

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

1 participant