is / capture misbehavior in grpc mock with docker on a Git runner

[christopher-watanabe-snkeos]

Describe the bug
I'm hosting my mock service with docker in a git runner (ubuntu 22.04). No issues with the service itself, it is contactable. However the IS statement in the following mock, which takes the below posted TestRequest as input, is misbehaving:

{{#is (capture using='jsonpath' selector='$.example.field') '==' 'success' }}
{
    "field_1": "successful_example",
    "field_2": "{{randomValue type='ALPHABETIC' length='5'}}"
}
{{else}}
{
  "error": {
    "code": 2,
    "message": "Unsuccessful example field: {{capture using='jsonpath' selector='$.example.field'}}"
  }
}
{{/is}}

Here is my proto definition:

message TestRequest {
  Example example = 1;
}

message Example {
  string field = 1;
}

message TestResponse {
  string field_1 = 1;
  string field_2 = 2;
}

service TestService {
  rpc TestRpc(TestRequest) returns (TestResponse);
}

When I run tests on this mock where I have the request example.field value set to success, it fails with the following output in my terminal:

2024/02/16 16:15:54 ERROR rpc error: code = Unknown desc = Unsuccessful example field: success"

This shows despite the example.field having been shown to be success, the mock still chooses to return the error and I can't understand why.

NOTE: The mock behaves correclty when I run with camouflage. I see this behavior when I am running with docker on a Git runner.

To Reproduce
Steps to reproduce the behavior:

1. Setup camouflage in a git workflow
2. Run the mock with docker
3. Make a request to the mock rpc with example.field = 'success'
4. Check response

Expected behavior
I would expect if the error message from the rpc is saying that example.field is equal to 'success', then an error would not be returned, but rather the repsonse given in the first block of the IS.

Desktop (please complete the following information):

• OS: ubuntu 22.04 (current ubuntu-latest version of Git Runner)

[christopher-watanabe-snkeos]

My guess is that this is related to #193, which was fixed and set to completed on Jul 18, 2023, but the latest release on docker was more than year ago. That would mean the fix I need isn't available in the published docker containers, which makes this also related to #236.