Excessive calls to ref requests

[gerukin]

Hi Andreas, here's another friendly bug report...

Note: I get the same behavior in the CLI.

Given this:

### Parent
# @name parent
https://httpbin.org/status/204

### Child
# @name child
# @ref parent
https://httpbin.org/status/200

### GrandChild
# @ref parent
# @ref child
https://httpbin.org/status/200

When I click send on the Child I get this as expected:

---------------------

=== Parent ===

GET https://httpbin.org/status/204
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 204  - NO CONTENT
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:16:06 GMT
server: gunicorn/19.9.0

---------------------

=== Child ===

GET https://httpbin.org/status/200
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 200  - OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-length: 0
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:16:06 GMT
server: gunicorn/19.9.0

When I click (same session) send on the GrandChild I get this:

---------------------

=== Parent ===

GET https://httpbin.org/status/204
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 204  - NO CONTENT
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:19:07 GMT
server: gunicorn/19.9.0

---------------------

=== Parent ===

GET https://httpbin.org/status/204
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 204  - NO CONTENT
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:19:08 GMT
server: gunicorn/19.9.0

---------------------

=== Child ===

GET https://httpbin.org/status/200
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 200  - OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-length: 0
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:19:09 GMT
server: gunicorn/19.9.0

---------------------

=== GrandChild ===

GET https://httpbin.org/status/200
accept-encoding: gzip, deflate, br
accept: */*
user-agent: httpyac

HTTP/1.1 200  - OK
access-control-allow-credentials: true
access-control-allow-origin: *
connection: close
content-length: 0
content-type: text/html; charset=utf-8
date: Tue, 28 Jun 2022 04:19:09 GMT
server: gunicorn/19.9.0

I would expect not to see already executed requests being called again (here neither Parent nor Child should run again, both both do - in fact, Parent does twice because it is also referenced in Child, which should not run again to begin with).

Maybe I misunderstood the intent of ref and forceRef.

Use case

I have a use case where I first run an endpoint which is not supposed to be called again within X min. This is considered an error and I have tests to ensure this indeed does error out.

### I should work
# @name save
http://{{SOME_PATH}}

### I should fail
# @ref save
http://{{SOME_PATH}}

In the CLI I run both in one go. First one succeeds as expected, and the second triggers the first one (fails since it expects to succeed) followed by itself (succeeds since it expects an error). In the extension I have the same problem but it doesn't really bother me there since I don't really need to run the second one. Of course, I could just remove the @ref in the second one so it works as expected in the CLI. But then it means I cannot run it independently of the first one anymore.

[AnWeber]

No, you probably already understood the intention of @ref and @forceRef correctly. The reason was that the check whether the child request was already executed was faulty due to the falsy body. I only checked for falsy instead of correctly checking for undefined.