Couldn't start Pact Verifier process with PID

[jonoc330]

Hi guys, I recently started writing some code to verify pacts. For some reason every time I get "Couldn't start Pact Verifier process with PID: *" even though I've tried cleaning running instances. Any advice you guys could give for getting around this issue? On Mac OS.

[ichyr]

hi, @jonoc330. Have you tried:

1. running it with different port
2. killing all processes node related
3. checking if PID is not in use by some other application

Please post a screenshot of command you try to run in terminal and output of it's execution.

[jonoc330]

Thanks @ichyr ! I haven't tried running it with a different port, although I'm not entirely sure pact-node gives you the option to. How would I go about doing that? Killed all processes node related (even just ended up restarting my computer at one point), and the PIDs being outputted arent being used.

[ichyr]

@jonoc330

Running with different port is shown here: https://github.com/pact-foundation/pact-node#create-pact-mock-server

Full example can be seen few line higher.

[jonoc330]

@ichyr that's for consumer contract creation right? I'm attempting to verify on the provider side. Assumed the provider lib was doing that for me.

[mefellows]

Hi @jonoc330 - any chance you could provide a gist of the pact-verification.js file?

Assuming you have tried the usual process removal of ./node_modules and re install etc., could you please try running ./node_modules/.bin/pact-provider-verifier directly?

This library essentially wraps an underlying Ruby process, so it's possible to rule in/out JS issues if you can't run it directly.

[jonoc330]

https://gist.github.com/jonoc330/9916ce6f6e44db213f43d66dcd13ff24

I'll try running it directly.

[mefellows]

Looks pretty reasonable, although I'm guessing you've sanitised things?

Let us know how the direct execution goes, that should help us rule out a few things.

[jonoc330]

So interestingly enough, running it via direct execution works perfectly!

Command I ran:

./pact-provider-verifier --provider-base-url=http://localhost:8080 --pact-urls=/path/to/contract.json --provider-states-url=http://localhost:8080/states --provider-states-setup-url=http://localhost:8080/setup

[mefellows]

I've seen this sort of issue before. I'm wondering if it's like some sort of network configuration - e.g. perhaps it's listening on 127.0.0.1 and not 0.0.0.0 (i.e. all interfaces) and that's why node can't detect that it's up?

Next steps would be to confirm the arguments flowing through to the mock service are correct (as per your manual steps) and then to see if the mock server is actually starting, but node is unable to connect.

e.g. you should be able to run a netstat -an | grep LISTEN when you kick this process off to see if any new ports have spun up, and the interfaces they're listening on. Also, the mock service, if indeed it is starting, should generate some logs - they might also give us some clues.

[jonoc330]

Arguments flowing through from node:

pact-provider-verifier --provider-base-url "http://localhost:8080" --pact-urls "/path/to/contract.json" --provider-states-url "http://localhost:8080/states" --provider-states-setup-url "http://localhost:8080/setup"

Basically the same thing.

[jonoc330]

Okay i've figured it out. The timeout is set to 10000ms which isn't long enough for the pacts to fail and return. I'm purposefully failing my pact verification at the moment which takes 51.34 seconds in a direct execution run. It's actually working in the background and verifying the pacts but the Node code assumes a long run time = failed start of the pact verifier process.

return deferred.promise.timeout(10000, "Couldn't start Pact Verifier process with PID: " + this._instance.pid) .tap(function (data) { logger.info('Pact Verification succeeded.'); });

[mefellows]

Interesting, I think we should make this timeout configurable (and also fix the error message - it's misleading). I'll look into this.

Also, great work :)

[jonoc330]

Awesome, that'll help loads.

Cheers for your help Matt!

[mefellows]

No worries, take a look at PR #31 if you're desperate for a fix in the meanwhile.

[mefellows]

v4.8.0 just released!