Skip to content

[release/9.0] [OpenAPI] Use invariant culture for TextWriter #62239

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

Open
wants to merge 1 commit into
base: release/9.0
Choose a base branch
from

Conversation

martincostello
Copy link
Member

@martincostello martincostello commented Jun 4, 2025

Use culture-invariant TextWriter implementation for OpenAPI.

Port of #62193 for .NET 9.

Description

To avoid any accidental changes to SignalR's use of Utf8BufferTextWriter I've removed the use of the writer pooling for OpenAPI and instead a new instance is created every time.

Fixes #60628

Customer Impact

Developers run into this issue when hosting under non-en cultures, but no workarounds are available.

Regression?

  • Yes
  • No (Bug has existed throughout 9.0 previews; not a regression from an earlier serviced release.)

Risk

  • High
  • Medium
  • Low

Change is isolated to the OpenAPI serialization path and uses an existing overload; no impact on runtime behavior or other subsystems.

Verification

  • Manual
  • Automated

Packaging changes reviewed?

  • Yes
  • No
  • N/A

Ensure OpenAPI documents are written to a culture-invariant `TextWriter` implementation.

Resolves dotnet#60628.
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Jun 4, 2025
@dotnet-policy-service dotnet-policy-service bot added this to the 9.0.x milestone Jun 4, 2025
@martincostello martincostello added feature-openapi area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc labels Jun 4, 2025
@martincostello martincostello deleted the gh-60628-9 branch July 17, 2025 10:49
@dotnet-policy-service dotnet-policy-service bot removed this from the 9.0.x milestone Jul 17, 2025
@martincostello martincostello restored the gh-60628-9 branch August 1, 2025 09:11
@martincostello martincostello reopened this Aug 1, 2025
@captainsafia
Copy link
Member

@martincostello I updated the issue with the servicing template in case you'd like to review it and mark the PR as ready for review.

@martincostello martincostello marked this pull request as ready for review August 6, 2025 18:11
@Copilot Copilot AI review requested due to automatic review settings August 6, 2025 18:11
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR addresses a culture-invariant formatting issue in OpenAPI document generation. When hosting applications under non-English cultures (like fr-FR), the OpenAPI serialization was producing incorrect JSON with locale-specific number formatting (e.g., using commas instead of dots for decimals).

  • Introduces a new constructor for Utf8BufferTextWriter that accepts an IFormatProvider
  • Updates the OpenAPI endpoint handler to use CultureInfo.InvariantCulture for serialization
  • Refactors test approach from direct document serialization to HTTP endpoint testing

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
Utf8BufferTextWriter.cs Adds constructor overload accepting IFormatProvider for culture-invariant formatting
OpenApiEndpointRouteBuilderExtensions.cs Updates OpenAPI serialization to use invariant culture and creates new writer instance instead of pooled one
OpenApiDocumentIntegrationTests.cs Simplifies tests to use HTTP client instead of direct document service
Program.cs Adds middleware to set French culture for testing culture-invariant behavior
TestController.cs Adds test endpoint with float property to verify decimal formatting
Multiple snapshot files Updates test snapshots with new server URL and endpoint entries

@martincostello
Copy link
Member Author

@captainsafia Thanks, done. I wanted to make sure you were happy with the changes/approach first before trying to guide it through shiproom.

@captainsafia captainsafia added the Servicing-consider Shiproom approval is required for the issue label Aug 6, 2025
Copy link
Member

@captainsafia captainsafia left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

servers change to snapshots is expected since we move from resolving the document via the service to via the endpoint.

New test scenario matches what we have in main.

@leecow leecow added Servicing-approved Shiproom has approved the issue and removed Servicing-consider Shiproom approval is required for the issue labels Aug 12, 2025
Copy link
Contributor

Hi @@martincostello. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

@leecow leecow added this to the 9.0.10 milestone Aug 12, 2025
@danmoseley
Copy link
Member

@captainsafia tactics approved but asked the usual question about whether we scanned for variants (other instances)?

@wtgodbe
Copy link
Member

wtgodbe commented Aug 13, 2025

Holding this for October at this point

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-minimal Includes minimal APIs, endpoint filters, parameter binding, request delegate generator etc community-contribution Indicates that the PR has been added by a community member feature-openapi Servicing-approved Shiproom has approved the issue
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants