Skip to content

mur check truncates diagnostics at 100 chars unconditionally, making long-path build failures unreadable #1273

Description

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:

  1. Don't truncate E-severity diagnostics — errors are what the user must act on.
  2. Add --no-truncate / --width <n>, and make --final imply it.
  3. 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

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions