[cli] bru run gets unexpected `401 Unauthorized` error for whatever run

hmeng1024 commented 6 months ago

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug

Issue Bru cli - bru run always gets a 401 Unauthorized error and that blocks every test from bru cli, while at the same time same request can be executed successfully from bru client. (see pic-1 and pic-2 attached)

Context

The bru run was doing good at the starting 2-3 days after i installed it about 10 days ago. Back at that time i can bru run folder successfully with more than 10 req inside. (it was likely at client v1.12.x, bru ver not sure now)
then some days later, it starts to fail with this issue found.

What have been tried

upgrade client and cli to latest v1.14.0
re-install the bru cli
narrow down the scenario from folder to single request, from token-required scenario to token-generation scenario

With above attempts, the issue is still there and shows exactly same error. The attached pics (pic-1 and pic-2) show a temp request in temp folder doing a token api test. It can still run with Client runner successfully, but bru cli fails the same.

Bru run traceback The traceback shows AssertionError as 200 is expected in the Test. While if the test script is commented out, we can still see the 401 Unauthorized error (see pic-2).

❯ bru run temp/temp.bru --env UAT
(node:87674) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Running Request

temp/temp (401 Unauthorized) - 432 ms
[Function: AssertionError]
AssertionError: expected 401 to equal 200
    at VM2 Wrapper.apply (/usr/local/lib/node_modules/@usebruno/cli/node_modules/vm2/lib/bridge.js:485:11)
    at /Users/hmeng/space/bruno_collections/console_hh/vm.js:3:32
    at VM2 Wrapper.apply (/usr/local/lib/node_modules/@usebruno/cli/node_modules/vm2/lib/bridge.js:485:11)
    at /usr/local/lib/node_modules/@usebruno/cli/node_modules/@usebruno/js/src/test.js:3:11
    at VM2 Wrapper.apply (/usr/local/lib/node_modules/@usebruno/cli/node_modules/vm2/lib/bridge.js:485:11)
    at module.exports (/Users/hmeng/space/bruno_collections/console_hh/vm.js:1:94)
    at VM2 Wrapper.apply (/usr/local/lib/node_modules/@usebruno/cli/node_modules/vm2/lib/bridge.js:485:11)
    at TestRuntime.runTests (/usr/local/lib/node_modules/@usebruno/cli/node_modules/@usebruno/js/src/runtime/test-runtime.js:143:11)
    at runSingleRequest (/usr/local/lib/node_modules/@usebruno/cli/src/runner/run-single-request.js:326:40)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async Object.handler (/usr/local/lib/node_modules/@usebruno/cli/src/commands/run.js:421:22) {
  showDiff: true,
  actual: 401,
  expected: 200,
  operator: 'strictEqual'
}
   ✕ Get token successfully
   ✓ Save token in VAR

Requests:    1 passed, 1 total
Tests:       1 passed, 1 failed, 2 total
Assertions:  0 passed, 0 total
Ran all requests - 432 ms
}
   ✕ Get token successfully
   ✓ Save token in VAR

I'm not sure if i'm the only person experiencing this issue so far. It appears either 1) it's a local env config issue from my own or 2) likely a bug from bru cli run workflow. Can anyone pls shed some light here?

.bru file to reproduce the bug

No response

Screenshots/Live demo link

pic-1

pic-2

hmeng1024 commented 6 months ago

hmmmm...maybe i didn't describe the issue clearly - I know 401 Unauthorized looks just like i miss authorization stuff.

To make the issue more specific - Difference observed (with same simple request) between Bruno Client run and bru cli run. Wondering if there is certain a debug way we can observe verbose execution details from bru run?

like -vvv, sh -x way to see more details at bru cli execution time?

Anybody pls could advise?

Its-treason commented 6 months ago

@hmeng1024 It's a bit hard to narrow down without seeing the exact Bru file.

How does the authorization on the Endpoint work? Could you instead make a request to something like: https://httpbin.org/anything and see any differences in the responses? You can also log the req and res using console.log inside your script.

CLI and Electron/Client have different implementations for making requests, that often causes issues.

hmeng1024 commented 6 months ago

@Its-treason Thank you for your reply and advice. It helped!

The req with pre-request scripts helped me to locate the issue and there DOES have a bug in bru cli when processing Secret value from VARs.

Basically what happened is one of my password VAR used in the PUT body cannot be resolved when it's a Secret field.

This perfectly explains why it was working for me at the beginning but broken some days later (when i set my password to Secret)

Quick replication as below and that should be fair enough for a bug fix request :0

❯ bru run httpbin --env Local
(node:57459) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Running Folder

baseUrl: http://httpbin.org
httpbin/httpbin - get (200 OK) - 498 ms

Requests:    1 passed, 1 total
Tests:       0 passed, 0 total
Assertions:  0 passed, 0 total
Ran all requests - 498 ms
❯
❯ bru run httpbin --env Local
(node:57467) [DEP0040] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead.
(Use `node --trace-deprecation ...` to show where the warning was created)
Running Folder

baseUrl: null
httpbin/httpbin - get (getaddrinfo ENOTFOUND null)

Requests:    0 passed, 1 failed, 1 total
Tests:       0 passed, 0 total
Assertions:  0 passed, 0 total

Its-treason commented 6 months ago

Yeah, that is a known Problem with secret variables: https://github.com/usebruno/bruno/issues/2015

hmeng1024 commented 6 months ago

ok, i read through the #2015 and looks we regard it as an expected behaviour with no fix/impr plan yet. While then as the author said there in #2015, it would be great if we can update relevant Bruno Doc to explicitly state this. :) But in general, all good then..thanks.

usebruno / bruno