Summary
mur check truncates every diagnostic message to 97 characters + ... (src/Reactor.Cli/Check/CheckCommand.cs:383):
var msg = Message.Length > 100 ? Message[..97] + "..." : Message;
No flag overrides it — --final and --strict truncate identically. For any diagnostic whose payload is a long path (APPX0002, MSB3541, most CS0246 assembly-resolution errors), the one piece of information needed to fix the build sits past the cut, and the user has to re-run dotnet build to recover it.
Impact: it systematically forces a dotnet build workaround
This isn't a one-off annoyance. Measured across 38 Reactor trials of an agent benchmark running 0.1.0-preview.15.13, correlating "did this trial hit a long-path build error" against "did this trial fall back to dotnet build":
|
dotnet build used |
not used |
| long-path error present |
26 |
0 |
| absent |
0 |
12 |
dotnet build was used if and only if a long-path error occurred — no exceptions in either off-diagonal cell. Trials with no path errors used mur check exclusively and never invoked dotnet build at all. mur check is the tool of choice throughout; the fallback exists purely to recover text that mur check had truncated (98 such invocations).
What it looks like
A session hitting a MAX_PATH-induced APPX0002:
mur check
... E APPX0002 Task 'WinAppSdkExpandPriContent' failed. Could not find file 'C:\Users\...\copilot-...
mur check --final 2>&1 | Out-String -Width 500 # tries to widen; still truncated
... E APPX0002 Task 'WinAppSdkExpandPriContent' failed. Could not find file 'C:\Users\...\copilot-...
dotnet build 2>&1 | Select-String "APPX0002" -Context 0,5 # recovers it
error APPX0002: ... Could not find file '...\obj\Debug\net10.0-windows10.0.26100.0\win-x64\Reactor.Advanced.pri.xml'
Out-String -Width cannot help here — the truncation happens inside mur, before anything reaches stdout, so no terminal width, redirection or pipeline setting can recover the text. The only way to read the diagnostic is to stop using mur check for that build.
The underlying long-path failure is a separate matter and is already raised as #1271. This issue is only about mur check rendering that class of error unreadable; the same truncation applies to any diagnostic with a long-path payload.
Suggested fix
Any of:
- Don't truncate
E-severity diagnostics — errors are what the user must act on.
- Add
--no-truncate / --width <n>, and make --final imply it.
- Keep the one-line summary but append the full untruncated text for any diagnostic that was cut.
Option 2 looks closest to the existing design: --final's documented contract is "Emit every diagnostic, no ranker suppression", which a reader would reasonably expect to include the full message text.
Environment
mur 1.2430.276.24
Microsoft.UI.Reactor 0.1.0-preview.15.13
- Windows, .NET 10 SDK
Summary
mur checktruncates every diagnostic message to 97 characters +...(src/Reactor.Cli/Check/CheckCommand.cs:383):No flag overrides it —
--finaland--stricttruncate identically. For any diagnostic whose payload is a long path (APPX0002,MSB3541, mostCS0246assembly-resolution errors), the one piece of information needed to fix the build sits past the cut, and the user has to re-rundotnet buildto recover it.Impact: it systematically forces a
dotnet buildworkaroundThis isn't a one-off annoyance. Measured across 38 Reactor trials of an agent benchmark running
0.1.0-preview.15.13, correlating "did this trial hit a long-path build error" against "did this trial fall back todotnet build":dotnet builduseddotnet buildwas used if and only if a long-path error occurred — no exceptions in either off-diagonal cell. Trials with no path errors usedmur checkexclusively and never invokeddotnet buildat all.mur checkis the tool of choice throughout; the fallback exists purely to recover text thatmur checkhad truncated (98 such invocations).What it looks like
A session hitting a
MAX_PATH-inducedAPPX0002:Out-String -Widthcannot help here — the truncation happens insidemur, before anything reaches stdout, so no terminal width, redirection or pipeline setting can recover the text. The only way to read the diagnostic is to stop usingmur checkfor that build.The underlying long-path failure is a separate matter and is already raised as #1271. This issue is only about
mur checkrendering that class of error unreadable; the same truncation applies to any diagnostic with a long-path payload.Suggested fix
Any of:
E-severity diagnostics — errors are what the user must act on.--no-truncate/--width <n>, and make--finalimply it.Option 2 looks closest to the existing design:
--final's documented contract is "Emit every diagnostic, no ranker suppression", which a reader would reasonably expect to include the full message text.Environment
mur1.2430.276.24Microsoft.UI.Reactor0.1.0-preview.15.13