Skip to content

Conversation

@jamietanna
Copy link
Member

@jamietanna jamietanna commented Apr 7, 2025

As noted in #1274, there appears to be a modification of the underlying
operationId in a given Operation, which is leading to the Embedded
Spec getting a different operationId than our input specification.

This appears to be due to the reference to the Operation being
modified (unintentionally, it would seem) in OperationDefinitions,
resulting in a nameNormalizer'd operationId being emitted, instead
of the input specification's operationId.

We can make sure that this is documented behaviour for the future, for
anyone else modifying this file.

To allow users to modify this, we can introduce an opt-in Compatibility
flag, preserve-original-operation-id-casing-in-embedded-spec.

Although this would be ideally an opt-out, this has the risk of breaking
existing code, so we can't push it to users.

To make sure that the underlying operationId isn't (always) modified,
we can take a copy of the value and then only update it if it's not
opted-out.

This also wires in a new test-case to document behaviour and to catch
issues in the future.

Closes #1274.

Jamie Tanna added 2 commits April 7, 2025 10:05
As noted in #1274, there appears to be a modification of the underlying
`operationId` in a given Operation, which is leading to the Embedded
Spec getting a different `operationId` than our input specification.

This appears to be due to the reference to the `Operation` being
modified (unintentionally, it would seem) in `OperationDefinitions`,
resulting in a `nameNormalizer`'d `operationId` being emitted, instead
of the input specification's `operationId`.

We can make sure that this is documented behaviour for the future, for
anyone else modifying this file.

To allow users to modify this, we can introduce an opt-in Compatibility
flag, `preserve-original-operation-id-casing-in-embedded-spec`.

Although this would be ideally an opt-out, this has the risk of breaking
existing code, so we can't push it to users.

To make sure that the underlying `operationId` isn't (always) modified,
we can take a copy of the value and then only update it if it's not
opted-out.

This also wires in a new test-case to document behaviour and to catch
issues in the future.

Closes #1274.
@jamietanna jamietanna force-pushed the feat/compat-operation-id branch from cbc8f16 to e2ccc9c Compare April 7, 2025 10:08
@jamietanna jamietanna marked this pull request as ready for review April 7, 2025 10:09
@jamietanna jamietanna requested a review from a team as a code owner April 7, 2025 10:09
@jamietanna jamietanna added this to the v2.5.0 milestone Apr 7, 2025
@jamietanna jamietanna merged commit 1883b30 into main Apr 7, 2025
43 checks passed
@jamietanna jamietanna deleted the feat/compat-operation-id branch April 7, 2025 10:11
@jamietanna jamietanna added the bug Something isn't working label Apr 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

OperationID from embedded spec doesn't match the original spec

2 participants