fix: improve file writing logic with retry mechanism for locked files

[thomhurst]

Fixes #3022

[claude]

Claude finished @thomhurst's task —— View job

---

Pull Request Review

Reviewing PR #3160 that fixes issue #3022 regarding file writing logic with retry mechanism for locked files.

Todo List:

• Read and analyze the modified GitHubReporter.cs file
• Review code quality and best practices
• Check for potential bugs or issues
• Evaluate performance considerations
• Assess security concerns
• Review test coverage needs
• Provide comprehensive feedback

Code Review Feedback

✅ Code Quality & Best Practices

The implementation follows TUnit's coding standards well:

• Uses modern C# patterns with #if NET conditional compilation
• Proper async/await usage with cancellation support
• Clean separation of concerns with the IsFileLocked helper method
• Good use of exponential backoff with jitter for retry logic

✅ Implementation Details

Retry Logic (lines 229-252):

• 5 maximum attempts with exponential backoff (50ms * 2^(attempt-1))
• Random jitter (0-50ms) to prevent thundering herd
• Graceful failure after max attempts
• Console logging for debugging

File Lock Detection (lines 255-264):

• Windows-specific HResult checking (0x20, 0x21)
• Cross-platform string message checking
• Handles both sharing violations and lock violations

⚠️ Potential Issues

1. Cross-platform compatibility concern (line 260):

   var errorCode = exception.HResult & 0xFFFF;

   The HResult masking assumes Windows error codes. On Linux/macOS, this might not work as expected. Consider adding platform-specific handling or testing on non-Windows systems.

2. Silent failure after retries (lines 252-253):
   After 5 failed attempts, the method silently returns without indicating failure. Consider:

   Console.WriteLine($"Failed to write GitHub Summary after {maxAttempts} attempts");
   // Or throw an exception if this is critical

3. Potential race condition (lines 218-222):
   File size is checked before writing, but the file could be modified between the check and write operation. This is likely acceptable for this use case but worth noting.

✅ Performance Considerations

• Exponential backoff prevents excessive retries
• Jitter helps distribute retry attempts
• UTF8 byte counting is efficient
• File size check prevents writing beyond 1MB limit

✅ Security Concerns

• No security issues identified
• File path comes from trusted environment variable
• No user input is directly written to files
• Proper encoding (UTF8) is used

❓ Test Coverage Needs

The retry mechanism would benefit from unit tests covering:

• Successful write after retry
• Maximum attempts exceeded
• Different IOException scenarios
• Cross-platform behavior
• File size limit enforcement

Suggested test scenarios:

[Test] // Using TUnit syntax
public async Task WriteFile_RetriesOnFileLocked()
{
    // Mock IOException with file lock HResult
    // Verify retry attempts and eventual success
}

[Test]
public async Task WriteFile_FailsAfterMaxAttempts()
{
    // Mock persistent file lock
    // Verify max attempts reached
}

📝 Minor Suggestions

1. Line 245: Consider making the base delay configurable or documenting the choice of 50ms
2. Line 261: Add a comment explaining the HResult masking for Windows error codes
3. Line 249: Consider using structured logging instead of Console.WriteLine for better observability

Overall Assessment

This is a solid implementation that addresses the file locking issue effectively. The retry logic with exponential backoff and jitter is well-designed. The main concerns are around cross-platform compatibility and the silent failure mode after exhausting retries.

Recommendation: ✅ Approve with minor suggestions

The code follows TUnit's standards and solves the reported issue. Consider adding the suggested error logging and cross-platform testing to make it more robust.

---