Hi folks! I'm updating our provider verification tests, and have come across some interesting things around the

afterEach

hook. 1. The documentation for the lifecycle seems to be incomplete, as it doesn't mention when the

State Handler Teardown

step runs. After some trial and error, I believe the following is correct:

BeforeEach -> State Handler Setup -> Request Filter (request phase) -> Execute Provider Test -> Request Filter (response phase) -> AfterEach -> State Handler Teardown

Is this right? Happy to get a PR open to update the docs if this is correct. 2. Are there any constraints around the

afterEach

hook, such as maximum execution time? In the

afterEach

hook for our tests, I'm resetting some of the data in our test database, as per one of the use cases described for it in the docs. However, it seems that my

afterEach

hook does not always finish executing. I've littered it with logging debug statements and

try/catch

statements to find out exactly where it gets to, and there are no errors being thrown - the logging statements sometimes just stop. What might I be missing? Any help is appreciated! Thanks in advance 🙂

One moment, I’ll check the code

Thanks for the speedy (and late night) responses! 1 - sounds great, like I said, happy to help improve docs for others if I can. 2 - interesting - ok, glad to know I hadn't missed something obvious. I did dig into the code a little myself because my gut feeling was "is this just a missing

await

?", but didn't see an obvious cause. Again, happy to contribute. Do you have an idea of what the cause is already, or do you need anything else from me to help reproduce?

Ok, so some non-obvious context: 1) the way that pact-js works is to defer all the mock requests / contract checking to the Rust core (which is wrapped in the js dependency

pact-core

). 2) The rust core expects to call setup and teardown hooks on an endpoint running on your provider, but this is clumsy for most users in JS land 2) But, pact-js doesn’t “know” when the setup and teardown hooks happen. 4) To get around this (and to allow a DSL where you can provide native JS setup and teardown hooks), pact-js runs a proxy server (built with express) that proxies the app that you’re verifying. It catches the request to the setup hook, swallows it, and calls the user provided hook.

Right, that makes sense - I was curious about the motivation for the Express-based proxy, but that context really helps.

The reason that was done is because not every test has a state, so you can’t rely on the teardown call (because there might not be one)

I'm wondering if this placement is actually the issue. The call to

next()

to trigger subsequent middleware is happening before the call to the

afterEach

hook. Good shout on the "do teardown" state. I'll give that a go as an immediate workaround to unblock me, and then if I get chance, I will have a play about with the middleware execution order.

Yep.

Right, ok, because this middleware isn't actually being invoked after the main request processing, so it's trying to workaround that fact.

I think that might be a library.

Cool, ok. I'll try your suggested workaround for now, and then explore the underlying issue more if I get a chance. What's the normal process for tracking this kind of thing? Raise a bug issue in the repo?

A bug would be great. I’m no longer a maintainer, just an interested community member

And I appreciate your help all the more for it 😄 thanks again for the support!

You’re welcome!

Sounds interesting, thanks for sharing 🙂

In summary - 1) PRs for pact definitely appreciated - although maybe hold off on the documentation one, as it might not be true once the issue with the afterEach is fixed. 2) Sorry about the bug - it looks like I was the last person to touch that code, so I probably missed it at least once 3) I’m glad to hear that the workaround of a special state that everything has will work for you 🙌

Alas, we're using multiple. But it's not too much hassle to chuck the extra

given(...)

in the consumer tests.

Awesome!

I'll hold off on docs changes for now, but I'll get the bug raised for (2) later on today 🙂

Thank you! Here’s a direct link to make that as easy as possible. https://github.com/pact-foundation/pact-js/issues/new?assignees=&labels=bug&template=bug_report.md&title=