feat: Add integration description to replayed request ENV

[barthez]

Description

Using request customizer add integration description at X_PACT_DESCRIPTION to rack request env, similar to
X_PACT_PROVIDER_STATES. Remove this env in last middleware before rack reversed proxy. That would be accessible in custom middleware added to verifier.

Additionally, support v3 provider states as a list with name and parameters.

Reason

I'm implementing pact testing setup for GQL Gateway which basically passes the pact verification to downstream services connected to the gateway. I need the description so I could create a contract for the downstream service.

[bethesque]

I'm so sorry - I've only just seen this PR. Is it still required?

[barthez]

Yes! it would be great to have it!

[YOU54F]

Hi thanks for this @barthez, looks really interesting! Popping this on my radar to take a look at

[YOU54F]

This fails when parsing a v3 spec

header X-Gateway-Pact-States has field value "{\"name\"=>\"There is a greeting1\", \"params\"=>{\"id\"=>\"foo1\"}}\n{\"name\"=>\"There is a greeting2\", \"params\"=>{\"id\"=>2}}", this cannot include CR/LF

we would need to parse it into json, to pass it along the wire, I think

given this pact

{
  "consumer": {
    "name": "me"
  },
  "provider": {
    "name": "they"
  },
  "interactions": [
    {
      "description": "Provider state success",
      "providerState": "There is a greeting",
      "providerStates": [
        {
          "name": "There is a greeting1",
          "params": {
            "id": "foo1"
          }
        },
        {
          "name": "There is a greeting2",
          "params": {
            "id": 2
          }
        }
      ],
      "request": {
        "method": "GET",
        "path": "/somestate"
      },
      "response": {
        "status": 200,
        "headers": {},
        "body": {
          "greeting": "State data!"
        }
      }
    }
  ],
  "metadata": {
    "pactSpecificationVersion": "3.0.0"
  }
}

[YOU54F]

provider_states is always set, even if parsing a v2 spec. which means this block of code always runs, and the block beneath doesn't

pact-provider-verifier/lib/pact/provider_verifier/set_up_provider_state.rb

Line 67 in ea3f247

states: [provider_state],

with a v2 spec, we get a change in behaviour

{"rack.version"=>[1, 3], "rack.input"=>#<StringIO:0x0000000139657a90>, "rack.errors"=>#<StringIO:0x0000000139658710>, "rack.multithread"=>true, "rack.multiprocess"=>true, "rack.run_once"=>false, "REQUEST_METHOD"=>"GET", "SERVER_NAME"=>"example.org", "SERVER_PORT"=>"80", "QUERY_STRING"=>"", "PATH_INFO"=>"/somestate", "rack.url_scheme"=>"http", "HTTPS"=>"off", "SCRIPT_NAME"=>"", "CONTENT_LENGTH"=>"0", "rack.test"=>true, "REMOTE_ADDR"=>"127.0.0.1", "SERVER_PROTOCOL"=>"HTTP/1.0", "HTTP_VERSION"=>"HTTP/1.0", "X_PACT_DESCRIPTION"=>"Provider state success", "X_PACT_PROVIDER_STATES"=>[{"name"=>"There is a greeting", "params"=>{}}], "HTTP_HOST"=>"example.org", "HTTP_COOKIE"=>""}

"X_PACT_DESCRIPTION"=>"Provider state success"
"X_PACT_PROVIDER_STATES"=>[{"name"=>"There is a greeting", "params"=>{}}]

before change

{"rack.version"=>[1, 3], "rack.input"=>#<StringIO:0x0000000122dd5248>, "rack.errors"=>#<StringIO:0x0000000122dd5838>, "rack.multithread"=>true, "rack.multiprocess"=>true, "rack.run_once"=>false, "REQUEST_METHOD"=>"GET", "SERVER_NAME"=>"example.org", "SERVER_PORT"=>"80", "QUERY_STRING"=>"", "PATH_INFO"=>"/somestate", "rack.url_scheme"=>"http", "HTTPS"=>"off", "SCRIPT_NAME"=>"", "CONTENT_LENGTH"=>"0", "rack.test"=>true, "REMOTE_ADDR"=>"127.0.0.1", "SERVER_PROTOCOL"=>"HTTP/1.0", "HTTP_VERSION"=>"HTTP/1.0", "X_PACT_PROVIDER_STATES"=>[{"name"=>"There is a greeting"}], "HTTP_HOST"=>"example.org", "HTTP_COOKIE"=>""}

"X_PACT_PROVIDER_STATES"=>[{"name"=>"There is a greeting"}]

[YOU54F]

I would split out the interaction description change and the change to support multiple provider states into separate PR's.

Tests ideally should be added to cover the changes. which would have illustrated an issue with the processing on the v3 pact spec with providerStates set.

I used some custom middleware to require in an e2e test to give this a quick whirl

# frozen_string_literal: true

require 'pact/provider_verifier/custom_middleware'

class CustomVerifierMiddleware < Pact::ProviderVerifier::CustomMiddleware
  def call(env)
    puts env
    env['HTTP_X_GATEWAY_PACT_DESCRIPTION'] = env['X_PACT_DESCRIPTION']
    env['HTTP_X_GATEWAY_PACT_STATES'] = env['X_PACT_PROVIDER_STATES']

    @app.call(env)
  end
end