Read .NET driver log files with shared access by diemol · Pull Request #2865 · SeleniumHQ/seleniumhq.github.io

diemol · 2026-10-04T10:27:56Z

Thanks for contributing to the Selenium site and documentation!
A PR well described will help maintainers to review and merge it quickly

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, and help reviewers by making them as simple and short as possible.

Description

Adds examples/dotnet/SeleniumDocs/LogFile.cs with:
- LogFile.ReadLines(path): opens the log with FileShare.ReadWrite | FileShare.Delete, the same approach Troubleshooting/LoggingTest.cs already uses;
- LogFile.TryDelete(path): cleanup that ignores a log file still locked by the driver.
Chrome, Firefox and IE tests call LogFile.ReadLines(...) instead of File.ReadLines(...) and LogFile.TryDelete(...) instead of File.Delete(...) in cleanup. Edge's existing ReadLogLines helper now reads through LogFile.ReadLines.
Every call site is swapped on the same line, so no gh-codeblock line range in the docs moves; I checked that none of the changed lines are referenced by the docs.

Motivation and Context

On Windows, the driver log tests (ChromeTest.LogsLevel/ConfigureDriverLogs, EdgeTest.LogsToFile/LogsLevel/ConfigureDriverLogs) intermittently fail with:

System.IO.IOException: The process cannot access the file '...\tmpXXXX.tmp' because it is being used by another process.

The tests read the log right after driver.Quit() with File.ReadLines/File.ReadAllLines, which request exclusive read access while the driver process may still hold the file open for writing. Edge already retried the read for 10 seconds and still failed, so waiting doesn't help; opening the file with shared access does. These failures are a large part of the daily red .NET runs on Windows and are blocking #2863.

Complements #2864 (retry only failed tests): that one stops flaky tests from costing a full re-run; this one removes this flake.

Types of changes

Change to the site (I have double-checked the Netlify deployment, and my changes look good)
Code example added (and I also added the example to all translated languages)
Improved translation
Added new translation (and I also added a notice to each document missing translation)

Checklist

I have read the contributing document.
I have used hugo to render the site/docs locally and I am sure it works. (N/A: example tests only; docs line ranges unchanged)

🤖 Generated with Claude Code

https://claude.ai/code/session_01NUg261RgRsNLfjAXhj3FqP

Generated by Claude Code

The Chrome, Edge, Firefox and IE log tests read the driver log right after driver.Quit() with File.ReadLines/ReadAllLines, which request exclusive read access. On Windows the driver process can still hold the file open for writing, so the read fails with "The process cannot access the file ... because it is being used by another process". Edge already retried for 10 seconds and still failed, so waiting does not help. Add a LogFile helper that opens the log with FileShare.ReadWrite | FileShare.Delete (as Troubleshooting/LoggingTest.cs already does), and a TryDelete for cleanup that ignores a still-locked file. Each call site is swapped on the same line, so gh-codeblock line ranges in the docs are unchanged. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NUg261RgRsNLfjAXhj3FqP

qodo-code-review · 2026-10-04T10:29:00Z

PR Summary by Qodo

Read .NET driver logs with shared file access

🐞 Bug fix 🧪 Tests 🕐 10-20 Minutes

AI Description

• Open driver logs with shared access to prevent intermittent Windows file-lock failures.
• Use the shared reader across Chrome, Edge, Firefox, and IE log tests.
• Ignore locked-log deletion failures during test cleanup.

Diagram

graph TD
  Tests["Chrome Firefox IE tests"] --> Helper["LogFile helper"] --> Stream["Shared read stream"] --> Log["Driver log file"]
  Edge["Edge retry wrapper"] --> Helper
  Helper --> Cleanup["Best-effort delete"] --> Log

High-Level Assessment

A shared helper is appropriate: it applies the same file-sharing behavior across browser tests without duplicating stream handling. Retrying alone is insufficient for the lock observed in Edge, which already retries reads.

Files changed (5) +49 / -13

Bug fix (5) +49 / -13

ChromeTest.csUse shared reads and best-effort cleanup for Chrome logs +5/-5

Use shared reads and best-effort cleanup for Chrome logs
• Chrome log assertions now use LogFile.ReadLines. Cleanup uses LogFile.TryDelete so a log still held by the driver does not fail the test.
examples/dotnet/SeleniumDocs/Browsers/ChromeTest.cs

EdgeTest.csRead Edge logs with sharing inside the existing retry wrapper +2/-2

Read Edge logs with sharing inside the existing retry wrapper
• Both read paths in ReadLogLines now call LogFile.ReadLines. The existing IOException retry behavior remains unchanged.
examples/dotnet/SeleniumDocs/Browsers/EdgeTest.cs

FirefoxTest.csUse shared reads and best-effort cleanup for Firefox logs +4/-4

Use shared reads and best-effort cleanup for Firefox logs
• Firefox log assertions now use LogFile.ReadLines, and cleanup uses LogFile.TryDelete for the log file.
examples/dotnet/SeleniumDocs/Browsers/FirefoxTest.cs

InternetExplorerTest.csUse shared reads and best-effort cleanup for IE logs +2/-2

Use shared reads and best-effort cleanup for IE logs
• The IE log assertion now uses LogFile.ReadLines. Cleanup uses LogFile.TryDelete for the driver log; other temporary-file cleanup is unchanged.
examples/dotnet/SeleniumDocs/Browsers/InternetExplorerTest.cs

LogFile.csAdd shared-access driver log helper +36/-0

Add shared-access driver log helper
• Adds an eager line reader that opens log files with read/write and delete sharing. Adds a deletion method that ignores IOException when a driver still holds the log.
examples/dotnet/SeleniumDocs/LogFile.cs

netlify · 2026-10-04T10:29:13Z

✅ Deploy Preview for selenium-dev ready!

Name	Link
🔨 Latest commit	`9891d80`
🔍 Latest deploy log	https://app.netlify.com/projects/selenium-dev/deploys/6ac2300d7e41720008f2d9b4
😎 Deploy Preview	https://deploy-preview-2865--selenium-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

To edit notification comments on pull requests, go to your Netlify project configuration.

qodo-code-review · 2026-10-04T10:30:07Z

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

1. ~~Locked logs remain on developers' disks~~ ✓ Resolved

Description

LogFile.TryDelete catches every IOException from File.Delete and never retries the deletion.
If a driver still holds a log during test cleanup, the test's temporary file remains after the lock
clears, and no later cleanup path removes it.

Code

examples/dotnet/SeleniumDocs/LogFile.cs[R30-33]

+            catch (IOException)
+            {
+                // Still held by the driver process; the OS temp directory cleans it up.
+            }

Evidence
The browser tests create log files with Path.GetTempFileName() and call TryDelete from test
cleanup. The new catch returns without recording the path or scheduling another attempt, so a
deletion that fails while the driver holds the file is not retried when the lock clears.
examples/dotnet/SeleniumDocs/LogFile.cs[24-34]
examples/dotnet/SeleniumDocs/Browsers/ChromeTest.cs[23-29]
examples/dotnet/SeleniumDocs/Browsers/ChromeTest.cs[171-178]
examples/dotnet/SeleniumDocs/Browsers/FirefoxTest.cs[20-29]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`LogFile.TryDelete` silently abandons a temporary driver log whenever deletion encounters an `IOException`. The lock may clear shortly afterward, but the tests make no further deletion attempt.

## Fix Focus Areas
- examples/dotnet/SeleniumDocs/LogFile.cs[24-33]

## Recommended Fix
Arrange a later, bounded deletion attempt for logs that are still locked during test cleanup. Make any log that remains undeleted observable rather than assuming the operating system will remove it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Context sources

Review mode: Auto: 🚀 Fast: This is a localized retry-and-cleanup behavior change in one self-contained helper, with limited blast radius and no high-risk domain involvement.

Tip of the day

💡 Did you know, you can describe a rule in plain language on the Rules page and Qodo drafts it for you

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 9891d80

Results up to commit e56b37f ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. ~~Locked logs remain on developers' disks~~ ✓ Resolved

Description

LogFile.TryDelete catches every IOException from File.Delete and never retries the deletion.
If a driver still holds a log during test cleanup, the test's temporary file remains after the lock
clears, and no later cleanup path removes it.

Code

examples/dotnet/SeleniumDocs/LogFile.cs[R30-33]

+            catch (IOException)
+            {
+                // Still held by the driver process; the OS temp directory cleans it up.
+            }

Evidence
The browser tests create log files with Path.GetTempFileName() and call TryDelete from test
cleanup. The new catch returns without recording the path or scheduling another attempt, so a
deletion that fails while the driver holds the file is not retried when the lock clears.
examples/dotnet/SeleniumDocs/LogFile.cs[24-34]
examples/dotnet/SeleniumDocs/Browsers/ChromeTest.cs[23-29]
examples/dotnet/SeleniumDocs/Browsers/ChromeTest.cs[171-178]
examples/dotnet/SeleniumDocs/Browsers/FirefoxTest.cs[20-29]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`LogFile.TryDelete` silently abandons a temporary driver log whenever deletion encounters an `IOException`. The lock may clear shortly afterward, but the tests make no further deletion attempt.

## Fix Focus Areas
- examples/dotnet/SeleniumDocs/LogFile.cs[24-33]

## Recommended Fix
Arrange a later, bounded deletion attempt for logs that are still locked during test cleanup. Make any log that remains undeleted observable rather than assuming the operating system will remove it.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

The OS does not clean up %TEMP% on Windows, so a log that is still locked during test cleanup was left behind. Retry the delete for up to two seconds and write a warning to stderr if the file is still locked. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NUg261RgRsNLfjAXhj3FqP

diemol · 2026-10-04T10:53:10Z

tests (windows, nightly) failed on e56b37f only on BiDi.CDP.LoggingTest.ConsoleLogs (timeout at LoggingTest.cs:29, both attempts). That is not caused by this PR:

The same failure happened on Retry only failed .NET example tests in CI #2864 (3 of 3 attempts) with Selenium.WebDriver 4.51.0-nightly202610040103.
It only failed on Windows nightly. Ubuntu nightly and Windows stable pass it.
This PR does not touch LoggingTest.cs.

Update: on 9891d80 the same job passed with the same nightly (202610040103), including ConsoleLogs, so it is intermittent on some Windows runners rather than broken in that nightly. All checks are green now.

Generated by Claude Code

qodo-code-review · 2026-10-04T10:53:35Z

Code review by qodo was updated up to the latest commit 9891d80

qodo-code-review Bot reviewed Oct 4, 2026

View reviewed changes

Comment thread examples/dotnet/SeleniumDocs/LogFile.cs Resolved

diemol merged commit bb9487d into trunk Oct 4, 2026
8 checks passed

diemol deleted the dotnet-log-file-share branch October 4, 2026 19:33

Navigation Menu

Repository navigation

Read .NET driver log files with shared access - #2865

Read .NET driver log files with shared access#2865
diemol merged 2 commits into
trunkfrom
dotnet-log-file-share

diemol commented Oct 4, 2026

Uh oh!

qodo-code-review Bot commented Oct 4, 2026

Uh oh!

netlify Bot commented Oct 4, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Oct 4, 2026 •

edited

Loading

Uh oh!

Uh oh!

diemol commented Oct 4, 2026 •

edited

Loading

Uh oh!

qodo-code-review Bot commented Oct 4, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

diemol commented Oct 4, 2026

Description

Motivation and Context

Types of changes

Checklist

Uh oh!

qodo-code-review Bot commented Oct 4, 2026

PR Summary by Qodo

Uh oh!

netlify Bot commented Oct 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for selenium-dev ready!

Uh oh!

qodo-code-review Bot commented Oct 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

diemol commented Oct 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

qodo-code-review Bot commented Oct 4, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

netlify Bot commented Oct 4, 2026 •

edited

Loading

qodo-code-review Bot commented Oct 4, 2026 •

edited

Loading

diemol commented Oct 4, 2026 •

edited

Loading