windows: stop leaking directory handles in test teardown, and decode server logs leniently

[oyvindberg]

Two Windows-only CI failures, both caused by code that is merely untidy on POSIX. Independent of #624 — no workflow changes, no overlap.

1. DirectoryNotEmptyException out of test teardown

29 test files each carried their own copy of:

Files.list(path).toScala(List).foreach(deleteRecursively)

Files.list returns a stream backed by an open directory handle. Materialising it with .toScala(List) never closes that handle, so it lives until GC gets around to it. On POSIX nothing notices. On Windows a directory entry with a live handle isn't removed when you delete it, only marked delete pending — so the children look deleted, and removing the parent then fails with DirectoryNotEmptyException.

That's how it surfaced on windows-latest (run 30456495265): PlatformCancellationTest passed its assertion —

+ Pre-cancelled Kotlin/JS compilation correctly returned ThreadOutcome.Cancelled

— and then threw out of the finally block:

java.nio.file.DirectoryNotEmptyException: C:\...\Temp\kotlin-js-cancel-10020005492201092876
  at bleep.analysis.PlatformCancellationTest.deleteRecursively(PlatformCancellationTest.scala:29)

830 passing tests, one failed run. Which of the 29 gets hit depends on GC timing — that's why Windows read as flaky rather than broken.

Replaced all 29 with one top-level deleteRecursively in bleep.analysis, built on Files.walkFileTree: the JDK's own recursive-delete recipe, which closes each directory stream before postVisitDirectory deletes the directory. Top-level, so no test needs an import. Seven files were left with an unused StreamConverters import that -Werror rightly rejected; those are gone too.

2. Build failed: Input length = 1

BspRifle.readOutput / readOutputTail and one diagnostic path in BspServerOperations read the server's captured stdout/stderr with Files.readString / Files.readAllLines. Both decode as strict UTF-8 and throw MalformedInputException on the first byte that doesn't decode.

That log isn't ours — it's whatever the server and every subprocess it spawned wrote, and on Windows that routinely includes console-codepage bytes. One stray byte in a diagnostic log was enough to fail the build that was reading it, with a message that names neither the file nor the cause.

containsOomMarker already got this right, with a comment saying exactly why:

lossy decode: the log interleaves subprocess output that need not be valid UTF-8, and a diagnosis helper must not throw over it

So this is finishing a job already started: that lossy read is promoted to BspServerOperations.readLogFile and the other three call sites now use it.

Verification

macOS: full bleep-bsp-tests green (648 passed, 0 failed, 73 suites), whole build compiles, bleep fmt clean.

The Windows behaviour itself can only be confirmed by CI — I can't reproduce either failure locally. #2 in particular is a strong inference from the error string plus the pre-existing comment on containsOomMarker, not something I observed directly; the failing stack never reaches the log because the top-level handler prints only the message.

Not fixed here

The ubuntu-22.04 / ubuntu-22.04-arm failures are unrelated: the compile-server self-deadlock from #622, where a test fork is charged CPU twice and every permit ends up held by a task waiting for a permit that can't exist. Symptom is 26-29 minutes of total silence before the job ceiling kills it. #623 fixes that (e3ad7bf0) and is the only PR currently passing both Linux jobs.

🤖 Generated with Claude Code