Blazor WASM: timed-out debugger connection can terminate a live attachment retry
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 22/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 活発
- 技術スタック
- csharp, typescript, vscode, wasm
- 領域
- devtools
調査の方向性
Start with the CorDebugConnection.ReadHandshakeAsync failure and the native monovsdbg_wasm connection lifecycle, then read the linked investigation in microsoft/aspire PR 20404 for the connection timelines. The issue leaves open whether the fix belongs in VSWebAssemblyBridge or the native debugger, so confirm ownership with maintainers first. Done means closing an abandoned opening attempt no longer kills the debugger used by a live retry, shown by the delayed-WebSocket reproduction.
索引モデルが issue の本文から書いたものです。
説明
Description
Blazor WASM debugging can fail when js-debug times out an initial WebSocket connection and retries. Cleaning up the abandoned connection can terminate monovsdbg_wasm, breaking the live retry.
What happens
- js-debug abandons its first WebSocket opening attempt after two seconds and retries.
- Both attempts establish connections to the native debugger.
- If the abandoned attempt completes its native connection first, closing it can cause the native debugger to exit.
- The live retry then fails in
CorDebugConnection.ReadHandshakeAsync.
Expected: Closing an abandoned opening attempt should not kill the debugger used by a live retry.
The exact fix ownership between VSWebAssemblyBridge and the native debugger still needs confirmation.
Reproduction and environment
Observed in real Windows x64 application-debugging runs with VS Code 1.130.0, C# 2.148.23, and .NET 11.
Also reproduced outside Aspire using the unmodified debugger/bridge, a simulated browser, and delayed WebSocket opening responses. Reversing the native connection order leaves the debugger alive.
The controlled reproduction also fails with C# 2.160.4 on Windows ARM64; that is not an x64 application-level result.
Evidence
- 主要言語
- TypeScript
- スター
- 3.1k
- フォーク
- 740
- 平均マージ
- 1日 3時間
- マージ済み PR（30日）
- 52
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
dotnet/vscode-csharp のほかの issue
-
Remove temporary .NET 11 CI container digest pin再び着手できるかも このイシューのプルリクエストはマージされずにクローズされました。 オープンInfrastructure Test
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
dotnet/vscode-csharp#9791 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
C#DK untriaged
難易度 3/5 1〜2日 初心者へのやさしさ 25/100
dotnet/vscode-csharp#9911 ·
メンテナーはふだん 1 日以内に返信
-
reporteオープンC#DK untriaged
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
dotnet/vscode-csharp#9910 ·
メンテナーはふだん 1 日以内に返信
-
aオープンC#DK untriaged
難易度 3/5 1〜2日 初心者へのやさしさ 25/100
dotnet/vscode-csharp#9901 ·
メンテナーはふだん 1 日以内に返信
-
Debugger untriaged
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
dotnet/vscode-csharp#9891 · コメント 6 件 ·
メンテナーはふだん 1 日以内に返信
dotnet/vscode-csharp の issue をすべて見る
似ている issue
-
bug require-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
expressjs/expressjs.com#2549 · リアクション 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
umami-software/umami#4686 · コメント 1 件 ·
メンテナーはふだん 2 日以内に返信
-
[Bug]: Device screenshot fails with 500 on iPhone Duo (Xcode 27.2): serve-sim calls simctl without --display対応中かも このイシューにリンクされたプルリクエストがオープン中、またはマージ済みです。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
pingdotgg/t3code#24900 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
inu-appcenter/UNIDorm-web#411 ·
メンテナーはふだん 1 日以内に返信
-
🐛 bug
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
メンテナーはふだん 2 日以内に返信