remote_coverage_tools/Main reports success on I/O error

[sputt]

Description of the bug:

If an I/O error occurs when writing coverage.dat via LcovPrinter.java, the exception is swallowed and the return code is not checked in Main.

The exception is converted to a bool here:

bazel/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/LcovPrinter.java

Line 50 in d7a9bb5

return false;

The return value is ignored here:

bazel/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/Main.java

Line 178 in d7a9bb5

LcovPrinter.print(new FileOutputStream(outputFile), coverage);

This situation can be particularly bad if remote caching is enabled, since a truncated or otherwise invalid lcov database can be uploaded to the cache, since the action succeeded.

Which category does this issue belong to?

Core

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I originally confirmed the issue by overriding remote_coverage_tools and patching LcovPrinter.print to return false unconditionally, which sure enough, produces a 0 byte lcov database but doesn't fail the action.

Which operating system are you running Bazel on?

Any

What is the output of bazel info release?

release 7.1.1

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

https://github.com/bazelbuild/bazel.git
d7a9bb5b1e345097820a89fcda106dc7eb7d3fa0

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

This was always a problem.

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

I suggest we modify LcovPrinter.print with throws IOException. See commit here:
sputt@9897443

[fmeum]

@c-mita That looks like a simple oversight to me, do you agree?

[c-mita]

Yeah that looks like a simple oversight. Probably simplest to just leave the exceptions intact and handle them in the Main class; there doesn't seem to be any value in converting to a boolean; especially as the code seems to be trying to do this twice within the call stack but not actually handling returned boolean.

[iancha1992]

A fix for this issue has been included in Bazel 7.2.0 RC1. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.2.0rc1. Thanks!