Dynamic disabling behavior ignored in CLI with pre scripts

[gerukin]

Given this test file:

{{
  httpRegion.metaData.disabled = true
}}

### Test 1
https://httpbin.org/status/200

Or the variant which executes before every request:

{{+
  httpRegion.metaData.disabled = true
}}

### Test 1
https://httpbin.org/status/200

Running:

httpyac --all ./requests/bugs/246.http --output short

I get the following in the CLI:

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

=== Test 1 ===

GET https://httpbin.org/status/200
=> 200 (731 ms, 184 B)

I expected the request to be ignored. Not sure if I'm doing something wrong but, see the related issue regarding some interesting vscode behavior.

[AnWeber]

• The first example has two httpRegions (1 global and the one with the request) and therefore does not work, because only first httpRegion is disabled.
• The second example fails because the check takes place only before the execution of the httpRegion. But using {+ ...}} is executed only meanwhile. I will extend the check.

[gerukin]

Ok, I'm starting to understand it a bit better, thanks.

So, I understand the first example disables a global httpRegion which doesn't impact the request because it is executed in a different httpRegion (it's own).

What is the global httpRegion used for (if anything)?

For the second example, the httpRegion is the request's, but the check on its meta data runs before the pre-script so the value is ignored. I understand you will change that. Thank you. 🙇‍♂️

What was / is the correct way to disable the request dynamically?

[AnWeber]

What is the global httpRegion used for (if anything)?

These regions are executed exactly once for each execution. So you can easily set variables for all further regions/requests. These were the reason for the strange name httpRegion. Request would not have fit.

What was / is the correct way to disable the request dynamically?

Originally I wanted to achieve this example, only then it didn't work out so great for me either and that's why I don't really use disabled at the moment.

### needsLogin
GET https://httpbin.org/action=needsLogin

{{
  httpFile.httpRegions[1].metaData.disabled = (response.statusCode !== 200);
}}
### login

GET https://httpbin.org/anything?action=dologin

Probably the best would be to put directly at disabled an expression that is evaluated between each step of the execution.

### login
# @disabled checkForLogin
GET https://httpbin.org/anything?action=dologin

[gerukin]

Nice example.

For context here's one of the use cases I have:

1. set a RUN_WRITE_TESTS env variable to true or false
2. selectively disable some requests in production (either for an entire file, or for specific requests within a file)

I think your suggestion for @disabled makes sense. Simple and flexible. There are a few things to think about though... like whether pre-scripts and/or referenced requests are always executed or not.

### Will I run?
# @disabled {{ _disabled }}
{{tokenService}}/check
  ?token={{_token}}
{{
  module.exports._disabled = !_token
}}

### I am disabled, but what is my name: {{ name }}
# @disabled {{ !_token }}
{{tokenService}}/check
  ?token={{_token}}
{{
  module.exports.name = 'my name is Andreas'
}}

### Will I get a token if there currently is none?
# @ref getToken
# @disabled {{ !_token }}
{{tokenService}}/check
  ?token={{_token}}

### Maybe with this syntax I would
# @ref getToken if {{ !_token }}
# @disabled {{ !_token }}
{{tokenService}}/check
  ?token={{_token}}

[AnWeber]

My idea was to check before each action. The alternative would be only at the position where disabled was inserted. I like the first idea better, as the second one is also easily solvable using {{ httpRegion.metaData.disabled = ...;}}.

# @disabled _disabled
<--- check for disabled
{{tokenService}}/check?token={{_token}}
<--- check for disabled
{{
  module.exports._disabled = !_token
}}

vs

# @disabled _disabled
<--- check for disabled
{{tokenService}}/check?token={{_token}}
{{
  module.exports._disabled = !_token
}}

[gerukin]

So if I understand you correctly... I could do something like this?

### Get token
# Gets a new token if we don't already have a valid, non expired token
# @name getToken
# @disabled {{ !tokenIsValid(_token) }}
{{tokenService}}/check
  ?token={{_token}}
{{
  module.exports._token = getToken(response)
}}

### Get private stuff
# @forceRef getToken
{{SUPER_SECRET_URL}}
Authorization: Bearer {{_token}}

1. no token -> both run
2. valid token -> only get private stuff runs
3. expired token -> both run

[AnWeber]

The syntax does not use brackets here. And it should be disabled if tokenIsValid (double negative?).

# @disabled tokenIsValid(_token)

1. yes both run, but using _token on first would result in Error, because _token is not defined. Use this._token instead.
2. yes, because disabled is checked before executing any action in region
3. yes, should be same as 1.

I would have just recreated the cases once with Jest and should work that way.

[AnWeber]

Change is released with version 5.4.0