Azure DevOps：「TF400898: An Internal Error Occurred. Activity Id: …」
Azure DevOps が自分の側で失敗し、理由は言いませんでした。TF400898 は HTTP 500 のときの言い方で、何が起きても同じ文面です。Activity Id は、Microsoft のログでのその要求の番号です。送るたびに新しくなります。この文面で終わるものは2種類あります。そのうち直るサービスの障害と、サービスが扱えない要求です。後者は、送るたびに失敗します。
返ってくるもの
REST API でプルリクエストを作った、公開の Dependabot for Azure DevOps の issue（2024年）からです。
POST https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repository}/pullrequests
500 Internal Server Error
{"$id":"1","innerException":null,"message":"TF400898: An Internal Error Occurred. Activity Id: b7ecf655-….","typeName":"Microsoft.Data.SqlClient.SqlException, Microsoft.Data.SqlClient","typeKey":"SqlException","errorCode":0,"eventId":0}
typeKey が示すのは、Azure DevOps の中のどこで壊れたか（ここではデータベース）です。要求の何が原因かは分かりません。
まず：毎回起きるか
- Azure DevOps の状態のページを見ます。2026年2月23日、Microsoft Q&A で、プルリクエストの作業中に TF400898 が出た人がいました。回答は、原因かもしれない Azure Repos の障害を状態のページから示し、それはもう直っていて、プルリクエストも使えるようになりました。
- 数分おいて、同じ要求をもう一度送ります。通れば、サービスの側でした。
- 一度にたくさん呼ぶと、ときどき失敗することがあります。Azure DevOps の Terraform プロバイダーには、
azuredevops_pipeline_authorizationをまとめてたくさん適用すると TF400898 が出るという未解決の issue（1448）があります。terraform apply -parallelism=1で抜けた人がいますが、遅くなります。 - 同じ要求が毎回失敗するなら、原因は要求の側です。これまでに分かっているものを下に並べます。
同じレビュアーが2回入ったプルリクエスト
2つの公開の報告が、同じ原因にたどり着いています。Azure CLI（issue 29914、2024年）では、同じメールアドレスが --required-reviewers と --optional-reviewers の両方にあると、az repos pr create が必ず TF400898 で失敗しました。Dependabot for Azure DevOps（上の issue）では、あるチームが担当者（assignee）とレビュアーの両方に書かれていました。Azure DevOps には担当者が無いので、拡張機能は2つの一覧を1つのレビュアーの一覧にまとめ、そのチームが2回入っていました。重なりを外すとプルリクエストが作れ、今は拡張機能が自分で重なりを取り除きます。
レビュアーの一覧には、同じ人やチームを1回だけ入れます。Web でも、レビュアーは必須か任意のどちらか一方です。
az repos pr create --source-branch feature/login --target-branch main --title "Login page" \
--required-reviewers alice@contoso.com --optional-reviewers bob@contoso.com長いファイルのパス
2026年2月、Microsoft Q&A で、あるチームが500文字を超えるパスのファイルを develop ブランチに push しました。リポジトリの Maximum path length のポリシーはオフだったので push は通り、そのファイルを入れたプルリクエストも通りました。その後、そのファイルのどれかを変えるプルリクエストは、すべて TF400898 で失敗しました。約400文字を超えると出たそうです。スレッドの回答によると、ポリシーがオフなら push は長いパスを受け付けますが、プルリクエストの裏のサービス（差分、マージの下見）にはもっと厳しい限度があり、文書には無く、ポリシーでも変わりません。
ブランチの中でいちばん長いパスを見るには：
git ls-files | awk '{ print length($0), $0 }' | sort -rn | headgit mv で短くします。そういうファイルの名前を変えるプルリクエストが通るかどうかは、スレッドに書かれていません。新しく入らないようにするには、Project settings → Repositories → Policies で Maximum path length をオンにします。Microsoft のリポジトリの設定のページによると、オンにしたときの既定の限度は248です。
他に出る場面
- 組織を Microsoft Entra につなぐとき（「failed to connect to the … Microsoft Entra tenant」）：2026年1月の Microsoft Q&A で、Azure DevOps のチームの話として、原因はユーザー プリンシパル名（UPN）の重複、つまりテナントに同じ UPN のユーザーが2人いること、という回答がありました。
- 新しい Azure Resource Manager のサービス接続を保存するとき：2023年の Q&A で、支払い方法の期限切れで Azure のサブスクリプションが止まっていた人がいて、それを直すと通りました。
- microsoft/CSEDevOps の Run Pipelines のタスクで、object のパラメーターをその場で渡したとき（issue 54、2025年、未解決）。
- Visual Studio Marketplace に拡張機能を上げるとき（vsce や、VsixPublisher の「VsixPub0029」）：2026年8月、Marketplace のチームは報告した人に VSMarketplace@microsoft.com へ連絡するよう求めました（microsoft/vsmarketplace の issue 2066）。
Microsoft に伝えるときは、どこであっても Activity Id と、タイムゾーンつきの時刻を添えます。
IntelliJ IDEA や Rider から Azure DevOps のプルリクエストを作るなら
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）と Android Studio のプラグインです。Git メニューに Azure DevOps のプルリクエストを作成… を足します。レビュアーの一覧は、リポジトリの最近のプルリクエストから人やチームを1回ずつ出すので、同じレビュアーを2回送ることはありません。Azure DevOps がこのようなエラーを返したときは、Azure DevOps が書いたとおりの文面を、Activity Id も含めて見せます。プルリクエストの作成は Pro（月 US$1・30日間の無料試用つき）、受信箱は無料です。画面は日本語です。
Azure DevOps と Azure Repos は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：「TF401179: An active pull request for the source and target branch already exists」 · 「TF401028: The reference … has already been updated by another client」 · English