anything after a slash in providerBaseUrl gets ignored when verifyProvider is run

[ewortzman]

Software versions

• OS: Linux
• Consumer Pact library: n/a
• Provider Pact library: pact-js 4.2.1
• Node Version: 6.11.3

Expected behaviour

Requests are sent to the url provided by providerBaseUrl with the path defined in the contract appended

Actual behaviour

Anything after a slash in the providerBaseUrl is dropped before the path defined in the contract is appended. For example, if the providerBaseUrl is http://localhost:8081/myProvider and the request is GET /api/cool/stuff, the actual request is sent to http://localhost:8081/api/cool/stuff instead of http://localhost:8081/myProvider/api/cool/stuff.

Steps to reproduce

0. This requires node.js and python installed.
1. clone this repo: https://github.com/ewortzman/pact-provider-verify-demo.git
2. in the root directory, run npm install
3. cd test
4. in one terminal, run python reflect.py. This starts a simple reflect server that prints any requests it receives to the console and responds with a 200.
5. in another terminal, run mocha provider-contract.js. This will attempt to verify the contract that is included in test/pacts/myconsumer-myprovider.json against the reflect server. It will pass, because all it expects is a 200, but the bug is evident in the output of the reflect server.

At this point, you will see in the output of the reflect server that the request for a provider state is correctly going to /myProvider/api/_pact/state, but the request defined by the contract is going to /api/cool/stuff, erroneously omitting the leading /myProvider.

[mefellows]

AFAIK this is expected behaviour. Perhaps the parameter name is confusing, however this makes sense. The contract specifies a very specific path, so we must test that the service works on that path else we can't guarantee the contract is working as expected.

@bethesque - thoughts?

[ewortzman]

If this is expected behavior, it eliminates the ability to run the same contract against a different instance of the same provider running at a url with a slash. I'll give you a real example from my use case.

We are using DC/OS to deploy our services. DC/OS is capable of maintaining multiple namespaces in folders. It provides urls that include the folders, allowing you to uniquely identify your service.

So I may have the same service running in a development namespace at http://dcos_url.com/development/myProvider and in an integration namespace at http://dcos_url.com/integration/myProvider. It would be useful to be able to run the same contract against both instances. After all, they're the same service. I shouldn't need to modify the contract to verify the both.

[bethesque]

@ewortzman that makes sense. I'll see what I can do.

[bethesque]

I've fixed the reverse proxy so that the path is taken into consideration. Can you update to standalone v1.21.0 when you have a moment @mefellows.

[bethesque]

Obviously, as Matt says, you take a risk when you're doing this, because you're getting less confidence from your verifications. But given that the path configuration is likely to be static (eg. it's not going to change between builds, it's a set and forget thing) I think the risk is worth the payoff.

[ewortzman]

hey @bethesque, how do I update the standalone if I have pact-js installed for a specific project? Or is that not something I should do and I should wait for you to do another release of pact-js?

Also, the same question for pact-python.

[mefellows]

It's in some upstream components. I'll update them now and will make generally available in the 4.x.x and 5.x.x releases tomorrow.

[mefellows]

FYI I'm having some trouble updating to the latest, some tests have failed and I'm just investigating. Please bare with me.

[mefellows]

v5.x.x will be out shortly - this should fix your issue!

[mefellows]

This should now be available in both the 4.x.x and 5.x.x releases:

See npmjs.com/package/pact (4.x.x) and npmjs.com/package/@pact-foundation/pact (5.x.x).

Note latest builds have been migrated to the pact-foundation scope in line with other JS packages.