Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Because Maths: invalid pact specification version supplied: 5 #1185

Closed
rholshausen opened this issue Mar 3, 2024 · 8 comments
Closed

Because Maths: invalid pact specification version supplied: 5 #1185

rholshausen opened this issue Mar 3, 2024 · 8 comments
Labels
awaiting feedback Awaiting Feedback from OP bug Indicates an unexpected problem or unintended behavior triage This issue is yet to be triaged by a maintainer

Comments

@rholshausen
Copy link

I got me some of this:
image

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

@rholshausen rholshausen added bug Indicates an unexpected problem or unintended behavior triage This issue is yet to be triaged by a maintainer labels Mar 3, 2024
@JP-Ellis
Copy link
Contributor

JP-Ellis commented Mar 3, 2024

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.

@rholshausen
Copy link
Author

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.

@JP-Ellis
Copy link
Contributor

JP-Ellis commented Mar 4, 2024

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:

export const numberToSpec = (
spec?: number,
defaultSpec: SpecificationVersion = SpecificationVersion.SPECIFICATION_VERSION_V2
): SpecificationVersion => {
if (!spec) {
return defaultSpec;
}
switch (spec) {
case 2:
return SpecificationVersion.SPECIFICATION_VERSION_V2;
case 3:
return SpecificationVersion.SPECIFICATION_VERSION_V3;
case 4:
return SpecificationVersion.SPECIFICATION_VERSION_V4;
default:
throw new Error(`invalid pact specification version supplied: ${spec}`);
}
};

@mefellows
Copy link
Member

mefellows commented Mar 4, 2024

Can you please show the MessageConsumerPact constructor you used (i.e. the setup code)?

@mefellows mefellows added the awaiting feedback Awaiting Feedback from OP label Mar 4, 2024
@mefellows
Copy link
Member

mefellows commented Mar 4, 2024

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.

@rholshausen
Copy link
Author

Ah, you are correct.

  // Specification Version (should be 3 for messages)
  spec?: number;

This is confusing. Also not having V4 support for asynchronous messages.

@mefellows
Copy link
Member

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.

@mefellows
Copy link
Member

I'll close this and open a feature request for Async Messages

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting feedback Awaiting Feedback from OP bug Indicates an unexpected problem or unintended behavior triage This issue is yet to be triaged by a maintainer
Projects
None yet
Development

No branches or pull requests

3 participants