Recently, we discovered some strange behavior on p...
# general
h
Recently, we discovered some strange behavior on pact stub server that when the server start with large JSON contract (50mb), it took significantly longer duration to response (5s per each in avg), what could be a potential issue on this? and what would you recommend us to do?
m
I’d start with creating a repro and raising an issue here: https://github.com/pact-foundation/pact-stub-server
h
I see, I will raise the issue there!
thankyou 1
m
Thanks. It will be interesting to see if it’s purely about the size, or if it’s about the variety of interactions - my guess is that the server is iterating all interactions to find the right match on each request, and perhaps that handling could be improved (e.g. by using a trie or an alternative data structure)
h
we do have a lot of variety of interactions, and most of them may contains a conflict of predicate, this is also one of the problem we discover when using pact with acceptance testing
👍 1
on our current practice, the deployment looks like this
m
Yeah, Joel has given me a bit of background on this. This is not an ideal use case for Pact, especially if you plan to verify that contract with a Pact Verification
but even with our BDCT feature (which would be better suited to this type of test). The contract is just so big, that it moves beyond what we would consider the scope of a “contract” test, and into other types of testing (which is obviously what you’re doing with it as well)
h
I see, and this is what we plan to do , we start test by writing a software rule (behavior-driven) then in the rule, we draft what provider should give to the system, then at the end of the test , it will produce same json contract which developer later can verify the contract compatibility with broker
is this considered as good practice following the BDCT practice you've mentioned?
I post some practical way of implement it here as well https://pact-foundation.slack.com/archives/C9UTHV2AD/p1721380524457569