Handle union types in parameters

[animeshjajoopostman]

Handle union types in parameters

JIRA: https://postmanlabs.atlassian.net/browse/AB-1295

Before:

After:

[github-actions]

unit test code coverage

Lines	Statements	Branches	Functions
	89.16% (5809/6515)	80.84% (3810/4713)	93.67% (859/917)

Coverage Breakdown • (89%)

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	89.16	80.84	93.67	89.28

report-only-changed-files is enabled. No files were changed in this commit :)

[github-actions]

integration test code coverage

Lines	Statements	Branches	Functions
	19.25% (2045/10620)	13.44% (998/7425)	19.86% (235/1183)

Coverage Breakdown • (19%)

File	% Stmts	% Branch	% Funcs	% Lines	Uncovered Line #s
All files	19.25	13.44	19.86	19.54

report-only-changed-files is enabled. No files were changed in this commit :)

[Copilot]

Pull Request Overview

This PR adds support for handling union types in OpenAPI 3.1.x parameters by selecting the first type from an array of types. OpenAPI 3.1.x allows parameters to have multiple types (e.g., ["string", "integer"]), and this change ensures the converter handles such cases gracefully.

Key changes:

• Added logic to detect union types in parameter schemas and select the first type
• Added comprehensive test coverage for union types in path, query, and header parameters

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
libV2/schemaUtils.js	Added union type handling logic in createProperties function
test/unit/convertV2WithTypes.test.js	Added comprehensive test case for union type parameter handling

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The comment should clarify what happens when the type array is empty or contains invalid types, and mention that this is a simplistic approach that may not handle all union type scenarios.

Suggested change

	// Pick the first type if it's a union of types
	// This simplistic approach picks the first type if it's a union of types.
	// If the type array is empty or contains invalid types, resolvedType will be undefined.
	// Note: This may not handle all union type scenarios supported by OpenAPI 3.1.x.

[Copilot]

This code doesn't handle the case where schema.type is an empty array, which would result in resolvedType being undefined. Consider adding a check for array length or providing a fallback type.

Suggested change

	// Pick the first type if it's a union of types
	const resolvedType = Array.isArray(schema.type) ? schema.type[0] : schema.type;
	// Pick the first type if it's a union of types, fallback to 'string' if array is empty
	const resolvedType = Array.isArray(schema.type)
	? (schema.type.length > 0 ? schema.type[0] : 'string')
	: schema.type;

[AyushShri]

const resolvedType = Array.isArray(schema.type) ? schema.type[0] : schema.type;

@animeshjajoopostman can you check this .

This code doesn't handle the case where schema.type is an empty array,

[AyushShri]

These changes look fine for parameters , but won't we face this same issue for responseHeaders as well.
We create separate properties for them at Line: 2499. ?

Also, as per the slack thread, this works fine for request/response bodies right. ?

[AyushShri]

Also, can you try to think if it will cause any issue once we plan to do 2-way-sync for OAS 3.1 ?

[animeshjajoopostman]

Missed adding it to response headers. I'll add them.
Yes, works fine for request and response bodies.

[animeshjajoopostman]

Also, can you try to think if it will cause any issue once we plan to do 2-way-sync for OAS 3.1 ?

Reverse syncing could overwrite the union of types defined in the specification with the first type picked for the collection.

For example: [string, integer] defined in the spec -> [string] after collection generation -> [string] in the spec post reverse syncing

Not specific to 2 way sync, but I'd assume an API consumer would want validations to kick in for all the types defined in the specification, and not just the first type.

This is just a fix/workaround, a proper solution needs time and needs to be thought through.

[animeshjajoopostman]

I've made the required changes, and I've updated the package version on beta.

You can test this change using this spec

[AyushShri]

So, this will cause problem later on when we plan on implementing 2 way Sync for OAS3.1 as the types would get updated in the spec without any change which is not expected.

[AyushShri]

any reason to change this ?

[animeshjajoopostman]

No, had changed it when trying something out. Let me revert