Suppress format warnings for response headers

[AayushP123]

Summary

Fixes #4227.

Skips unsupported-format validation for response and component header schemas. Kiota exposes response header values as strings, so validating their OpenAPI formats as generated model types produced warnings that users could not act on.

Changes

• Ignore direct response/component header schemas in both format validation rules.
• Match structural path segments so a model property named headers is still validated.
• Add regression tests for response headers, component headers, and similarly named model properties.
• Add a changelog entry.

Testing

• dotnet format whitespace kiota.slnx --no-restore --verify-no-changes --include over the four changed source/test files
• Focused validation tests (11 passed)
• dotnet test tests/Kiota.Builder.Tests/Kiota.Builder.Tests.csproj --no-restore (2,194 passed, 2 skipped)

[Copilot]

Pull request overview

Updates Kiota’s OpenAPI validation so that “unsupported format” warnings aren’t emitted for response header schemas, since Kiota surfaces response headers as string values and users can’t meaningfully act on those format warnings.

Changes:

• Skips InconsistentTypeFormatPair validation when the schema path is under an OpenAPI headers node.
• Adds a regression test for a Location response header using format: uri.
• Adds a changelog entry describing the behavior change.

Reviewed changes

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

File	Description
src/Kiota.Builder/Validation/InconsistentTypeFormatPair.cs	Adds a path-based early-return intended to suppress type/format warnings under OpenAPI headers.
tests/Kiota.Builder.Tests/Validation/InconsistentTypeFormatPairTests.cs	Adds a regression test asserting no warnings for a response header schema using format: uri.
CHANGELOG.md	Documents the suppression of response-header format warnings.

Suppressed comments (1)

src/Kiota.Builder/Validation/InconsistentTypeFormatPair.cs:56

• This change won’t suppress the warning reported in #4227: the message shown in the issue ("The format uri is not supported by Kiota and the string type will be used.") is emitted by KnownAndNotSupportedFormats, and InconsistentTypeFormatPair already short-circuits for formats in KnownAndNotSupportedFormats.knownAndUnsupportedFormats (which includes uri). To fully address the issue, the same /.../headers/... exclusion likely needs to be applied in KnownAndNotSupportedFormats as well.

        if (context.PathString.Contains("/headers/", StringComparison.OrdinalIgnoreCase) ||
            schema is null || !schema.Type.HasValue || string.IsNullOrEmpty(schema.Format) || KnownAndNotSupportedFormats.knownAndUnsupportedFormats.Contains(schema.Format) || escapedTypes.Contains(schema.Type.Value))
            return;
        var sanitizedType = schema.Type.Value & ~JsonSchemaType.Null;
        if (!validPairs.TryGetValue(sanitizedType, out var validFormats) || !validFormats.Contains(schema.Format))
            context.CreateWarning(nameof(InconsistentTypeFormatPair), $"The format {schema.Format} is not supported by Kiota for the type {sanitizedType} and the string type will be used.");

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (4)

src/Kiota.Builder/Validation/KnownAndNotSupportedFormats.cs:30

• IsHeaderSchema(context.PathString) is evaluated before checking schema.Format, so this path-splitting logic will run for every schema even when Format is null/empty. Reordering the condition avoids extra allocations and work during validation.

    public KnownAndNotSupportedFormats() : base(nameof(KnownAndNotSupportedFormats), static (context, schema) =>
    {
        if (!IsHeaderSchema(context.PathString) &&
            !string.IsNullOrEmpty(schema.Format) && knownAndUnsupportedFormats.Contains(schema.Format))
            context.CreateWarning(nameof(KnownAndNotSupportedFormats), $"The format {schema.Format} is not supported by Kiota and the string type will be used.");

src/Kiota.Builder/Validation/InconsistentTypeFormatPair.cs:53

• IsHeaderSchema(context.PathString) is checked first in the early-return condition, so it runs even when schema is null or when Format is empty/irrelevant. Put the header-path check last to short-circuit earlier and reduce per-schema overhead.

    public InconsistentTypeFormatPair() : base(nameof(InconsistentTypeFormatPair), static (context, schema) =>
    {
        if (KnownAndNotSupportedFormats.IsHeaderSchema(context.PathString) ||
            schema is null || !schema.Type.HasValue || string.IsNullOrEmpty(schema.Format) || KnownAndNotSupportedFormats.knownAndUnsupportedFormats.Contains(schema.Format) || escapedTypes.Contains(schema.Type.Value))
            return;

tests/Kiota.Builder.Tests/Validation/InconsistentTypeFormatPairTests.cs:124

• This test file covers suppressing warnings for response-header schemas, but InconsistentTypeFormatPair now also skips #/components/headers/.../schema. Adding a regression test for component headers would help prevent accidental reintroduction of warnings for reusable header components.

          headers:
            Location:
              schema:
                type: string
                format: int32

CHANGELOG.md:103

• The changelog entry mentions only response headers, but the change also suppresses warnings for components/headers schemas. Updating the entry to include component headers makes the release note accurate and easier to discover.

- Fixed unsupported type-format warnings for response header schemas, which are always emitted as strings. [#4227](https://github.com/microsoft/kiota/issues/4227)