Skip to content

Rolling Release 10.0.0 pre.20260806.4rc1 cherry-picks - #30687

Open
secondsun wants to merge 2 commits into
bazelbuild:release-10.0.0-pre.20260806.4rc1from
secondsun:release-10.0.0-pre.20260806.4rc1
Open

Rolling Release 10.0.0 pre.20260806.4rc1 cherry-picks#30687
secondsun wants to merge 2 commits into
bazelbuild:release-10.0.0-pre.20260806.4rc1from
secondsun:release-10.0.0-pre.20260806.4rc1

Conversation

@secondsun

Copy link
Copy Markdown

This PR cherry-picks 53428ca into the current rolling release.

aoeui and others added 2 commits August 12, 2026 13:42
…rations.

SafeExecutor wraps any executor that might be shut down. SafeExecutor
then hides the direct reference so that it cannot be used in an unsafe
manner making SafeExecutor safe to inject throughout the application code.

SafeExecutor compensates for common executor operations that can be
deadlock prone in the presence of executor shutdowns.

* Executor.execute - RejectedExecutionException is a RuntimeException so we
  don't usually explicitly handle it and there's no systematic enforcement
  mechanism. SafeExecutor requires a RejectionHandlingRunnable that has a
  rejection handling callback for safety.
* Futures.addCallback - quite surprisingly, Guava handles these by detecting
  RejectedExecutionException and logging, but doing nothing further. SafeExecutor
  forwards the RejectedExecutionException to the FutureCallback's onFailure
  method to ensure any dependent computations complete, rather than cause
  hung futures.

SafeFutures provides a number of wrapper methods, for common, already
safe operations like Futures.transform, and FutureCombiner.call. This
is necessary to fully encapsulate the executor.

MoreExecutors.directExecutor() operations are already safe so nothing
needs to be done in those cases.

SafeExecutor is in its own package, safeexecutor, to ensure outside
callers cannot call getInternalUnsafeExecutor.

PiperOrigin-RevId: 963007837
Change-Id: I9a195feca131a84cdf4c264f775e351399dd08e3
…iles (bazelbuild#30662)

### Description

`appendCoverageLog` copies `coverage.log` and `coverage.err` into the test log and then deletes them, but the `FileOutErr` that the coverage post-processing spawn wrote them through was never closed. This closes it before the delete, and also closes it on the paths that rethrow, which previously leaked the handles.

### Motivation

Deleting a file that still has an open handle is fine on POSIX, but not on Windows. Every affected test then fails with:

```
ERROR: ... Testing //tests/alwayslink_srcs:alwayslink_test failed: java.io.IOException: C:/b/skckkmg2/execroot/_main/bazel-out/x64_windows-fastbuild/testlogs/tests/alwayslink_srcs/alwayslink_test/coverage.err (Permission denied)
```

The bug is older than that, but it only became reachable for Bazel users with 8e68c24, which flipped `--experimental_split_coverage_postprocessing` to default true.

### Build API Changes

No

### Checklist

- [ ] I have added tests for the new use cases (if any).
- [ ] I have updated the documentation (if applicable).

### Release Notes

Closes bazelbuild#30662.

PiperOrigin-RevId: 962724931
Change-Id: Icb52f15e33291676ee7f96a0d2d4b22235bd5536
@secondsun
secondsun requested a review from pzembrod August 12, 2026 13:44
@github-actions github-actions Bot added the awaiting-review PR is awaiting review from an assigned reviewer label Aug 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-review PR is awaiting review from an assigned reviewer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants