[Bug] Different behavior of getHeaders in single request and collection run

[ahuemmer]

I like Bruno very much and it makes a real difference compared to other tools for its purpose, so that I signed up for the golden edition! Thank you for your effort!

Nevertheless, there's a nasty little issue I encountered testing my API via Bruno.

This is my test code:

test("Correct Content-Type is present", function() {
  console.log(res.getHeaders());
  expect(res.getHeaders()).to.have.property('content-type');
  expect(res.getHeader("content-type")).to.equal("application/json");
});

When I execute a get request individually (using the arrow in the upper right, besides the orange disk symbol), the test is executed correctly. The console output is:

{
    "content-type": "application/hal+json;charset=UTF-8",
    "content-length": "111",
    "server": "Werkzeug/1.0.1 Python/3.9.6",
    "date": "Tue, 23 Jan 2024 17:19:57 GMT",
    "request-duration": 15
}

However, if I run the same test as part of a folder within a collection (using the three dots beside the collection folder name and then choosing "Run"), the test fails, saying:

expected [ [ 'content-type', …(1) ], …(4) ] to have property 'content-type'

The console log indeed shows res.getHeaders() to be a two-dimensional array now:

[
    [
        "content-type",
        "application/json"
    ],
    [
        "content-length",
        "33"
    ],
    [
        "server",
        "Werkzeug/1.0.1 Python/3.9.6"
    ],
    [
        "date",
        "Tue, 23 Jan 2024 17:19:57 GMT"
    ],
    [
        "request-duration",
        9
    ]
]

Interestingly, this just applies to the second GET request in my collection folder. The first one contains the same test and executes fine in either way. I tried adding a third GET request and the problem persists (now for the second and third request).

[sanjai0py]

hey @ahuemmer, i tried that bug but it's working fine for me. maybe i missed something? could you add some pictures and explain more?

[zenum4]

I'm having the same problem with the same header (content-type).

[ahuemmer]

Hi @sanjai0py , thanks for your quick reply and support!
I have created a minimal example: Bug-1436.json
The crucial point seems to be, that the second request returns a 404 HTTP status. With 200, it works.
Here's a video of how I reproduced it.

[ahuemmer]

Update: Silly me, you don't even need the first request! The error occurs already when running the second one (returning 404) as the only request in the collection. (Running it like in the video, via the context menu besides the collection name --> "Run" --> "Run collection").

[zenum4]

It happens as well when the request is in the folder (even if it's the only request there).
Clicking Run on the folder results in the bug, while running the request directly works fine.

@sanjai0py Could you let us know if the above comments are enough explanation for you to start working on this issue?

[zenum4]

I've noticed it's not only related to 404, but also 400, 415 and 422 (at least in my case).
Probably it occurs for any 4xx error.

[helloanoop]

@ahuemmer Thank you for purchasing the Golden Edition 💛

@ahuemmer @zenum4 @sanjai0py I have fixed this bug. This will be shipped in the upcoming release (hopefully tonight)

[sanjai0py]

hey, that's really great that you fixed the issue, @helloanoop. i've also been working on it. can't wait for the fix to be merged so i can learn the code!

[ahuemmer]

Thank you @helloanoop , I can confirm that the issue is gone in 1.7.1. 🙂 Thanks a lot for the quick fix!