Increase namespace/type-name shortening threshold from 64 to 200

[ramsessanchez]

Description

Reduces the sensitivity of the recently-added namespace segment and type name shortening (PRs #7714, #7901) by raising the default length threshold from 64 to 255 characters. Names between 65 and 255 characters now keep their full names instead of being truncated and given a hash suffix.

Changes

• StringExtensions.DefaultMaxNameSegmentLength: 64 → 255 (+ doc)
• CommonLanguageRefiner.ShortenOversizedNamespaceSegments default maxSegmentLength: 64 → 255 (Java/Python/PHP/TypeScript refiners inherit the new default)
• Updated affected tests (StringExtensionsTests, JavaLanguageRefinerTests, PhpLanguageRefinerTests, TypeScriptLanguageRefinerTests) — assertion bounds and inputs adjusted so shortening is still exercised at the new threshold
• CHANGELOG entry under Unreleased

Out of scope

The file-name path shortening in the C#/Go/Ruby PathSegmenters is unchanged.

Testing

Targeted dotnet test over the 4 affected test classes: 116/116 passed, no new warnings/errors.

[github-code-quality]

Code Coverage Overview

Languages: C#

C# / code-coverage/dotnet

The overall coverage in the ramsessanchez/increa... branch is 72%. Coverage data for the main branch is not yet available.

Show a code coverage summary of the most covered files.

File	main	ramsessanchez/increa... 2da186a	+/-
/home/runner/wo...guageRefiner.cs	—	98%	—
/home/runner/wo...criptRefiner.cs	—	98%	—
/home/runner/wo...MethodWriter.cs	—	97%	—
/home/runner/wo...MethodWriter.cs	—	96%	—
/home/runner/wo...MethodWriter.cs	—	96%	—
/home/runner/wo...MethodWriter.cs	—	95%	—
/home/runner/wo...rs/GoRefiner.cs	—	93%	—
/home/runner/wo...KiotaBuilder.cs	—	90%	—
/home/runner/wo...ationService.cs	—	89%	—
/home/runner/wo...xGenerator.g.cs	—	75%	—

---

_{Updated July 09, 2026 00:15 UTC
Code Coverage is in Public Preview. Learn more and provide us with your feedback.}

[jingjingjia-ms]

Please correct me if I'm wrong: with the per-segment limit raised to 128, I think it can actually reintroduce the original problem #7713 was filed to fix.

Taking the deviceReport example from that issue — the directory segment (237 chars) and class name (251 chars) are both still over 128, so they do get trimmed, but only down to 126 chars each. Once you combine them with the namespace prefix and separators, the full path becomes:

D:\a\_work\1\s\kiota\output\com\microsoft\graph\beta\networkaccess\reports\microsoftgraphnetworkaccessdevicereportwithstartdatetimewithenddatetimediscoveredapplicationsegmentiddiscoveredapplicat_<8hex>\MicrosoftGraphNetworkaccessDeviceReportWithStartDateTimeWithEndDateTimediscoveredApplicationSegmentIdDiscoveredApplicat_<8hex>RequestBuilder.java

= 333 chars, back over the Windows MAX_PATH limit.

[gavinbarron]

TLDR; The limit is per-segment / per-name, not on the total path length.

Looking at the two decision points:

Namespace segments (line 1647):

if (segments[i].Length > maxSegmentLength) // each individual segment

The full namespace name is split on  .  and each segment is checked independently against  maxSegmentLength  (default 64). A namespace like  a.b.reallyLongSegment.c  only shortens  reallyLongSegment  if it alone exceeds 64 chars.

Type names (in  ShortenCodeElementNameIfOversized , line ~1687):

if (codeElement.Name.Length > maxSegmentLength) // each individual class/enum/interface name

Each class/enum/interface name is checked on its own against the same 64-char threshold.

What this means

• There is no accounting for total path length (root path + package dirs + all segments + filename). The fix caps each component to a bounded size and relies on the fact that bounding each component keeps the total comfortably under Windows MAX_PATH.
• The 64-char cap is deliberately conservative. In the reported case, the violation was caused by a single directory segment (~237 chars) and a single filename (~251 chars) — both individual components blowing past the limit. Capping each to ≤64 dropped the total from ~568 to ~215 chars (as traced in the plan).

Limits we need to be aware of

Assuming that the OS has LongPathsEnabled

Limit	Value
Single path component	255 characters (UTF-16 code units) this is the NTFS limit
Total path length	~32,767 characters

[ramsessanchez]

Correct me if im wrong, but at least for java this would result in breaking changes, as the file name must match the class name. A related concern is that for Java we actually encourage users to explicitly hardcode certain namespaces to disambiguate. Applying this fix across the board to namespaces also creates a possible breaking change.

[gavinbarron]

The fileName == className concern is already managed in the previous work.

this fix should be adjusted so that we only hit the cases where we were unable to produce the SDK due to truncation so that we don't introduce a v1 breaking change.

[ramsessanchez]

Sounds good, will increase our limit so our maximum output is 255 to reduce possible changes. Issue with namespace changes being impacted is unlikely as we currently do not have any folders reaching the limit so they will not be truncated hence any hardcoded namespaces should not be affected.