TF400898 - Maximum path length issue?

Question

Hi,

we curently have a strange but huge problem with Azure Devops.

We have successfully pushed some files/directories to our develop branch on 26.1 with some files, which has a path length of more than 500 and after this date we were not able to create any pull requests, which contains files with length of more than 400.

Its always the same kind of message shown

Is the max length 400 or 260 (long-standing restriction in Windows)?

The Maximum path length policy is switched off

https://learn.microsoft.com/en-us/azure/devops/repos/git/repository-settings?view=azure-devops&tabs=browser#maximum-path-length-policy

Answer 1

Hi @Alexander Roth

Thank you for reaching out to Microsoft Q&A.

I understand your issue however the overall experience was quite confusing and time‑consuming. Although Azure DevOps allows pushing files with very long paths (even beyond 500 characters) when the Maximum path length policy is disabled, Pull Request creation still fails due to stricter, undocumented limits enforced by internal PR processing services (diff generation, merge simulation, UI rendering, backend indexing). These limits are not related to the Windows 260‑character restriction and are not affected by disabling the Maximum path length policy, which only applies to push validation. Because of this, the PR fails with a generic TF400898: An Internal Error Occurred, without any indication that path length is the real cause. This makes the issue very hard to identify and can easily cost teams several hours of troubleshooting.

Please raise a ticket in Developer community so that the dedicated DevOps team can look into it: https://developercommunity.visualstudio.com/AzureDevOps

Based on the details shared, this behavior is related to how Azure DevOps enforces path length limits differently across operations. While Azure Repos allows pushing files with very long paths when the Maximum path length policy is switched off, Pull Request (PR) creation uses additional backend services such as diff generation, merge simulation, policy evaluation, and web UI rendering. These internal services still enforce stricter, non-configurable path length limits, which are lower than what Git storage allows. As a result, repositories can successfully store files with paths longer than 500 characters, but PRs start failing when paths exceed roughly 400 characters. This failure is surfaced as a generic TF400898: An Internal Error Occurred (often with a SQL exception), which unfortunately does not clearly indicate a path length issue. This limitation is not related to the Windows 260-character MAX_PATH restriction and is also not overridden by disabling the Maximum path length policy, as that policy only applies to push-time validation and not PR processing.

Refer below points to resolve this issue or use these as workarounds:

Reduce repository path lengths (Recommended and reliable solution) Azure DevOps Pull Request processing is more stable when full file paths are kept well below the observed limit. Refactoring directory structures and shortening folder or file names to keep paths under ~350 characters helps avoid PR creation failures, merge issues, and potential pipeline checkout problems.

Avoid relying on the Maximum path length policy for PRs The Maximum path length policy only affects push validation. Disabling it does not change the limits enforced during Pull Request creation, diff rendering, or merge simulation. Relying on this setting alone will not resolve PR failures caused by long paths.

Be cautious with platform-specific workarounds Settings such as enabling Windows long paths, using core.longpaths=true, or switching build agents (for example, Linux agents) may help with local development or pipeline checkout scenarios, but they do not fix Pull Request failures in Azure DevOps, as the PR logic runs on Azure DevOps backend services.

Plan repository structure for long-term compatibility Even if long paths can be pushed today, they can cause ongoing issues in PRs, pipelines, and tooling. Designing repository structures with shorter, flatter paths improves compatibility across Azure DevOps features and operating systems.