Response object not natively available when calling features from karate-config.js

[kirksl]

This issue started occurring with Karate 1.0

The following feature file will fail when called from karate-config with error org.graalvm.polyglot.PolyglotException: ReferenceError: "response" is not defined

This same feature file will succeed when called outside of/after karate-config

Scenario: this will fail
    * table params
        | param1 | param2 | param3 |
        | 'abc'  | 'def'  | 'ghi'  |
    * call read('classpath:com/repro/httpbin/httpbin.feature@endpoint=get_httpbin') params
    * def headers = response.headers

The same feature file, now edited, setting call to a variable and referencing the variable works

Scenario: this will succeed
    * table params
        | param1 | param2 | param3 |
        | 'abc'  | 'def'  | 'ghi'  |
    * def r = call read('classpath:com/repro/httpbin/httpbin.feature@endpoint=get_httpbin') params
    * def headers = r[0].response.headers

Attaching a demo project referencing the issue
myproject.zip

To Repro
Open /src/test/java/com/repro/tests/test.feature and run @test=test1 scenario
Witness error in console or /build/karate.log

Open /src/test/java/com/repro/setup/customers/customers_setup.feature and goto line 11 to reach problematic code.
Comment out option 1 section of code
Uncomment option 2 section of code
Run @test=test1 scenario again

[ptrthomas]

that's weird - since I'm having a very busy month cc @joelpramos since he is familiar with this code

[joelpramos]

I’m touching the calling of features with the fix I’m doing for #1793 so I’ll look into this one too.

[joelpramos]

@kirksl can you give it a try with the last commit at #1828

[kirksl]

@joelpramos i still see the issue when trying latest develop branch

[joelpramos]

Took a look into your scenario bit better - problem is when calling a Feature with an array (i.e. multiple executions) in sharedScope the variables are not getting propagated to the parent.

I noticed that when fixing the original issue that lead me to refactor some details on the callFeature (Config changes weren't getting propagated to caller in shared scope).

The fix is to replace ScenarioEngine.java:2053 with the following:

            if (resultVariables.isMap()) {
                setVariables(resultVariables.getValue());
            } else if (resultVariables.isList()) {
                ((List) resultVariables.getValue()).forEach(r -> {
                    setVariables((Map) r);
                });
            }

i.e. the else condition will try to propagate all variables of the called Feature. Looking for yours and @ptrthomas opinion though... how do we think this should behave? Since it's an iteration we'll have the same variables with multiple values (e.g. the response object itself in case of calling an API) so is there value in propagating the shared scope?

I guess that was the design pre v1.0 so I'm ok implementing that behavior (and do the same to propagate any Config changes) but I think we should maybe add a note in the documentation to avoid this as the order of the execution of the scenarios cannot be guaranteed.

[joelpramos]

Btw to reproduce just need to add an array as argument in the call of the following file: karate-core/src/test/java/com/intuit/karate/core/parallel/call-single-from-config3.feature .

Response will become an array thus it won't propagate the response to the caller.

[ptrthomas]

@joelpramos I'm ok to propagate, a call array loop always runs on one thread (scenario outlines can run in parallel)

[joelpramos]

@kirksl fixed in develop

[kirksl]

thank you @joelpramos
my test is limited, but this appears fixed.
once the issue below is fixed i can fully test this on my end
#1838

[ptrthomas]

1.2.0 released

[ptrthomas]

tagging this to #2009 - I'm going to undo this change. so a "call loop in shared scope" will never propagate variables back to caller. it doesn't make sense