fix(openapi): resolve streaming request name collision when multiple endpoints share a $ref body#14256
Draft
fix(openapi): resolve streaming request name collision when multiple endpoints share a $ref body#14256
Conversation
…endpoints share a $ref body
When two endpoints both use x-fern-streaming with stream-condition and
reference the same $ref request body schema, the auto-disambiguation
logic was deriving the streaming request name from the shared schema
name (e.g. NorthChatRequestInternalStreaming), causing duplicate
declaration errors.
Remove the ${schemaId}Streaming auto-disambiguation and instead let
convertHttpOperation's generatedRequestName (which is already unique
per endpoint via breadcrumbs with "stream" suffix) flow through as the
natural fallback. Explicit stream-request-name overrides still work.
Also adds multi-endpoint test coverage to the x-fern-streaming-with-reference
fixture to prevent regression.
Contributor
🌱 Seed Test SelectorSelect languages to run seed tests for:
How to use: Click the ⋯ menu above → "Edit" → check the boxes you want → click "Update comment". Tests will run automatically and snapshots will be committed to this PR. |
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
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.
Description
When two endpoints both use
x-fern-streamingwithstream-conditionand reference the same$refrequest body schema, the auto-disambiguation logic (introduced in #13568) derived the streaming request name from the shared schema name (e.g.,NorthChatRequestInternalStreaming). Since the name came from the$refrather than the endpoint, multiple endpoints sharing the same request body all produced the same streaming request name, causing"NorthChatRequestInternalStreaming is already declared in this file"errors.Changes Made
convertStreamingOperation.ts: Removed the${schemaId}Streamingauto-disambiguation. Now only passes through the explicitstream-request-nameuser override (if provided). Otherwise,convertHttpOperation'sgeneratedRequestName— which is already unique per endpoint via breadcrumbs with a "stream" suffix — flows through as the natural fallback.$refrequest body) to thex-fern-streaming-with-referencefixture in bothopenapi-ir-to-fern-testsandv3-importer-teststo cover the multi-endpoint collision case. Also added a third endpoint withoutx-fern-sdk-method-nameto exercise theoperationId-based breadcrumb path.Context on #13568
PR #13568 introduced the
${schemaId}Streamingauto-disambiguation to prevent streaming and non-streaming variants of a single endpoint from colliding when the request body is a$ref. We attempted to reproduce that original bug by running our updated fixture against the pre-#13568 code, but thegeneratedRequestName(breadcrumb-based) already produced unique names in all scenarios we tested — with and withoutx-fern-sdk-method-name, and with various$refschema names. The explicitstream-request-nameuser override added in #13568 is preserved and still works.Testing
openapi-ir-to-fern-testspassv3-importer-testspassfern checkagainst the Cohere spec that originally triggered this bug — 0 errors (previously 1 error)