Closed ColdFire87 closed 1 year ago
Also, this makes things pretty confusing, when discussing specification versions :)
export declare enum SpecificationVersion {
SPECIFICATION_VERSION_V2 = 3,
SPECIFICATION_VERSION_V3 = 4,
SPECIFICATION_VERSION_V4 = 5
}
Thanks again for this detailed bug report!
So there are a few things here:
V3
or greater, because message pact is only supported from V3.Promise<MessageFromProviderWithMetadata>
, using the providerWithMetadata
function (see https://github.com/pact-foundation/pact-js/blob/master/docs/messages.md#provider-producer). This is why the metadata validation is failing.I'll leave this ticket open to track these items.
metaData
metaData
property on an interaction, however it should use the metadata
property.Other items
export declare enum SpecificationVersion { SPECIFICATION_VERSION_V2 = 3, SPECIFICATION_VERSION_V3 = 4, SPECIFICATION_VERSION_V4 = 5 }
What's confusing about it? You should use the enum provided by the framework to set the spec version, not the value (implementation detail). Behind the scenes the specification is a zero-indexed enum.
Implemented your feedback and got it to work.
Metadata bug still in UI, but doesn't affect the verification.
export declare enum SpecificationVersion { SPECIFICATION_VERSION_V2 = 3, SPECIFICATION_VERSION_V3 = 4, SPECIFICATION_VERSION_V4 = 5 }
The confusing bit about the above comes when manually inspecting the pact (JSON), as a 4
actually means V3
for example.
Implemented your feedback and got it to work.
Great - thanks for confirming! I'll close this off now, as the bug in the UI is a Pactflow issue on the backlog to be resolved.
The confusing bit about the above comes when manually inspecting the pact (JSON), as a 4 actually means V3 for example.
Oh no. In the pact JSON file, 4 == 4
. It's just that the backing enums in the TS interface are indexed by 0.
Hi,
I have generated a pact for a message based interaction. The gist of it is:
Things I noticed when using different specification versions:
SPECIFICATION_VERSION_V1
orSPECIFICATION_VERSION_V2
,asynchronousBodyHandler
passes the following data to the callback:SPECIFICATION_VERSION_V3
,asynchronousBodyHandler
passes the following data to the callback:SPECIFICATION_VERSION_V4
is not supported byMessageConsumerPact
Regardless of using V1 or V2, the same pact contents is generated with this pact metadata:
Although I only specify
content-type
&x-kafka-topic
for the message metadata,contentType
is automatically added:AuditService-CardService_Async_V1_V2.json.txt
When using V3, I get this pact metadata:
The message metadata seems to be correct now (no additional
contentType
field added):AuditService-CardService_Async_V3.json.txt
On the provider side, I have this verification code:
where
buildMessage
is:The validation for the message body passes, but the one for the message metadata fails:
Other things I noticed:
metaData
field (capitalD
), whereas all contracts I generated (V1/V2/V3) havemetadata
metaData
:I believe, regardless of specification version, Pactflow expects
metaData
.The original thread of discussion on Slack -> https://pact-foundation.slack.com/archives/C9VBGLUM9/p1667408672806869