Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Nov 16, 2025

Fixes #(issue number needed)

Context

MSBuild throws fatal exceptions when replaying binlog files with format versions newer than supported, even when the minimum required reader version is within range. The minimum reader version field exists precisely to enable forward compatibility—older MSBuilds should read (possibly partial) logs from newer versions.

Example failure:

❯ dotnet msbuild newer.binlog
There was an exception while reading the log file: The log file format version is 26 with minimum required reader version 18, whereas this version of MSBuild only supports versions up to 25.

Changes Made

XMake.cs:

  • Enable AllowForwardCompatibility on BinaryLogReplayEventSource
  • Subscribe to RecoverableReadError for graceful error handling
  • Use BinaryReader overload to ensure compatibility flag is respected
  • Emit warning (non-fatal) when file version exceeds supported version but minimum reader version is compatible

BinaryLogger.cs:

  • Make FileFormatVersion constant public (was internal) for version comparison

BinaryLogger_Tests.cs:

  • Add tests for AllowForwardCompatibility property and public FileFormatVersion access

Testing

Verified with simulated binlog files:

  • Format v26, min reader v18: Warning displayed, replay succeeds
  • Format v26, min reader v26: Error displayed, replay fails (correct)
  • Format v25 (current): No warning, normal operation

Unit tests pass for new API surface.

Notes

Pre-existing test failures in BinaryLogger_Tests are unrelated (confirmed on base commit).

Original prompt

This section details on the original issue you should resolve

<issue_title>Command-line log replay is too aggressive about versioning</issue_title>
<issue_description>```sh-session
❯ dotnet msbuild -flp:v=diag -noconlog /Users/raines/Downloads/CentralNode_devenv_PID=38240_x64_BuildManager_DesignTimeBatchBuild_0.binlog
There was an exception while reading the log file: The log file format version is 25 with minimum required reader version 18, whereas this version of MSBuild only supports versions up to 23.


That message should definitely be emitted, but it should be nonfatal--the point of the "minimum required reader version" is to allow reading (possibly partial) logs from newer MSBuilds.</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@dotnet-policy-service
Copy link
Contributor

Hello @@copilot, I noticed that you’re changing an .swr file or any file under src/Package/MSBuild.VSSetup.. Please make sure to validate this change by an experimental VS insertion. This is accomplished by pushing to an exp/* branch, which requires write permissions to this repo.

Copilot AI and others added 5 commits November 16, 2025 22:13
- Set AllowForwardCompatibility = true when creating BinaryLogReplayEventSource
- Made BinaryLogger.FileFormatVersion public to allow version comparison
- Added warning message when log file version is newer than supported version
- Only fail when minimum reader version is too high (not just newer format)

Co-authored-by: JanProvaznik <[email protected]>
- Subscribe to RecoverableReadError event to satisfy forward compatibility requirements
- Output recoverable read errors as warnings to the console
- Tested: binlog replay now works correctly with current version binlogs

Co-authored-by: JanProvaznik <[email protected]>
- Test that BinaryLogReplayEventSource can be configured with AllowForwardCompatibility
- Test that BinaryLogger.FileFormatVersion is publicly accessible
- Both tests pass successfully

Co-authored-by: JanProvaznik <[email protected]>
- Modified Replay(string, CancellationToken) to properly pass forward compatibility flag
- Fixed warning message formatting to not depend on missing resource
- Tested: v26 binlog with min reader 18 shows warning and continues
- Tested: v26 binlog with min reader 26 correctly fails
- Tested: v25 binlog works without warnings

Co-authored-by: JanProvaznik <[email protected]>
- Changed XMake to manually open BinaryReader and use the overload that respects AllowForwardCompatibility
- Reverted changes to BinaryLogReplayEventSource.Replay(string, CancellationToken) to avoid test regressions
- Verified: v26 with min 18 shows warning and continues
- Verified: v26 with min 26 shows error and fails
- Note: Pre-existing test failures in BinaryLogger_Tests are not related to these changes

Co-authored-by: JanProvaznik <[email protected]>
Copilot AI changed the title [WIP] Fix command-line log replay versioning error Fix command-line binlog replay to respect minimum reader version Nov 16, 2025
Copilot AI requested a review from JanProvaznik November 16, 2025 22:44
Copilot finished work on behalf of JanProvaznik November 16, 2025 22:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Command-line log replay is too aggressive about versioning

2 participants