Closed gerukin closed 2 years ago
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.
Hi Andreas, here's another friendly bug report...
Note: I get the same behavior in the CLI.
Given this:
When I click
send
on theChild
I get this as expected:When I click (same session)
send
on theGrandChild
I get this:I would expect not to see already executed requests being called again (here neither
Parent
norChild
should run again, both both do - in fact,Parent
does twice because it is also referenced inChild
, which should not run again to begin with).Maybe I misunderstood the intent of
ref
andforceRef
.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.
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.