Because Maths: invalid pact specification version supplied: 5
rholshausen opened this issue · 8 comments
I assume this is just for the hell of it:
export enum SpecificationVersion {
SPECIFICATION_VERSION_V2 = 3,
SPECIFICATION_VERSION_V3 = 4,
SPECIFICATION_VERSION_V4 = 5,
}
https://github.com/pact-foundation/pact-js/blob/master/src/v3/types.ts#L3C1-L7C2
Isn't this the counterpart of the PactSpecification
enum defined in pact.h
?
/**
* Enum defining the pact specification versions supported by the library
*/
typedef enum PactSpecification {
/**
* Unknown or unsupported specification version
*/
PactSpecification_Unknown,
/**
* First version of the pact specification
*/
PactSpecification_V1,
/**
* Second version of the pact specification
*/
PactSpecification_V1_1,
/**
* Version two of the pact specification
*/
PactSpecification_V2,
/**
* Version three of the pact specification
*/
PactSpecification_V3,
/**
* Version four of the pact specification
*/
PactSpecification_V4,
} PactSpecification;
In which case V4
does correctly correspond to int 5
.
No, the issue is that PactV3Options has
/**
* Specification version to use
*/
spec?: SpecificationVersion;
https://github.com/pact-foundation/pact-js/blob/master/src/v3/types.ts#L102
If you try use that enum value SPECIFICATION_VERSION_V4 , you get that error.
It seems correct to me to use spec?: SpecificationVersion
with an enum. I'm guessing then that the num is incorrectly handled elsewhere and is converted to an integer in a somewhat naive way? Or perhaps some confusion between ints and enum values in:
Lines 3 to 21 in 59081f2
Can you please show the MessageConsumerPact
constructor you used (i.e. the setup code)?
I can see the problem, I think. The type MessageConsumerOptions
does not take the enum, it takes an integer (it predates the later interfaces which accept the enum because that would have broken the backwards-compatibility of the API): https://github.com/pact-foundation/pact-js/blob/master/src/dsl/options.ts#L104
It accepts an integer that maps logically to each version (1
= spec version 1, 2
= spec version 2 etc.). When you pass in the enum, the value is mapped to the core (as Josh has noted). Due to the zero indexing and the support for 1.1, Spec Version 4 maps to the integer 5
.
In any case, it's an unfortunate inconsistency in the interface. There is not yet a V4 version of Asynchronous Messages that aligns with the most recent DSL.
TL;DR - use 4
instead of the enum.
No, the issue is that PactV3Options has...
Where are you getting that type for? That's only used in the PactV3
type, not the messaging type.
Ah, you are correct.
// Specification Version (should be 3 for messages)
spec?: number;
This is confusing. Also not having V4 support for asynchronous messages.
Yeah, I have an open branch with partial support for the updated asynchronous interface (this was the original one that supported the Ruby messaging API, and doesn't support plugins etc.).
I'll update the comment for now.
I'll close this and open a feature request for Async Messages