fix(codegen): allow exposing the input spec's operationId #1945
Merged
jamietanna merged 2 commits intomainfrom Apr 7, 2025
Merged
fix(codegen): allow exposing the input spec's operationId #1945jamietanna merged 2 commits intomainfrom
operationId #1945jamietanna merged 2 commits intomainfrom
Conversation
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
force-pushed
the
feat/compat-operation-id
branch
from
cbc8f16 to
e2ccc9c
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As noted in #1274, there appears to be a modification of the underlying
operationIdin a given Operation, which is leading to the EmbeddedSpec getting a different
operationIdthan our input specification.This appears to be due to the reference to the
Operationbeingmodified (unintentionally, it would seem) in
OperationDefinitions,resulting in a
nameNormalizer'doperationIdbeing emitted, insteadof 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
operationIdisn'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.