1.1.0.RC2 : Error in running multiple mock feature files together

[rabacadabra]

I have two mock server feature files. There is a single POST endpoint defined in both the mocks which validates the request against a predefined schema, and responds back based on the validation.

When I'm running them individually using the -m option as given below, the endpoints are working as expected.
java -jar D:\karate-1.0.1\karate-1.1.0.RC2.jar -m a-mock.feature
java -jar D:\karate-1.0.1\karate-1.1.0.RC2.jar -m b-mock.feature

When I try running both the mock files together,
java -jar D:\karate-1.0.1\karate-1.1.0.RC2.jar -m a-mock.feature -m b-mock.feature
the schema check validation in a-mock doesn't seem to be working.

Both feature files contain a definition called schema which define the request structure and the schema check validation is done against this. On exploring further, I found out that if I made the definition name different in both feature files(eg:schemaA, schemaB), this issue is not happening. It seems that if its the same name, the def will get overwritten by the last feature file (In this case, the a-mock endpoint was validating the request against the schema defined in b-mock).

Is this by design, or is it a bug?

Below ZIP file contains the two feature files:
1.1.0.RC2-issue.zip

[ptrthomas]

I'll summon @dinesh19aug and @ivangsa who worked on #1566 to weigh in - this is not a priority for me

if there is no resolution within a week I'll move it to the project board

[rabacadabra]

@dinesh19aug / @ivangsa have you come across this issue? If so, how did you overcome this?

Please let me know if you need more details

[ivangsa]

Hi @rabacadabra,
yes this is somehow expected because how Background works on server side features:

Background is executed once on mock server startup to define configuration and global variables, (there is no concept of feature file local variables) so, as you pointed out, if you define two variables with the same name, second one will ovewrite the first one

We can update the documentation to point out this caveant... I didn't test it but I expect a warn log to show up when a variable is override this way..

[ptrthomas]

closing as wontfix discussion / PR can continue