Fallback test XML generator inherits the parent test’s resource requirements
- Dominant language
- Java
- Stars
- 25.8k
- Forks
- 4.6k
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 72
Description
### Description
When a test does not create XML_OUTPUT_FILE, `StandaloneTestStrategy` runs a fallback spawn that converts the test log into JUnit XML.
This spawn is constructed with both: `action.getExecutionInfo()` and `SpawnAction.DEFAULT_RESOURCE_SET`.
However, `SimpleSpawn.getLocalResources()` applies resource overrides parsed from the execution information. Consequently, resource tags belonging to the test - such as large CPU, memory, GPU, or custom-resource requirements—override the XML generator’s default resource set.
The lightweight XML generator can therefore request the same resources as the test it is reporting.
Relevant code:
[StandaloneTestStrategy](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/exec/StandaloneTestStrategy.java#L474-L487)
[SimpleSpawn.getLocalResources()](https://github.com/bazelbuild/bazel/blob/master/src/main/java/com/google/devtools/build/lib/actions/SimpleSpawn.java#L241-L253)
### Why this is a bug
The resource requirements describe the test workload, not the reporting helper. Resource estimates should be scoped to the spawn that consumes those resources.
Passing `SpawnAction.DEFAULT_RESOURCE_SET` suggests that the XML generator is intended to use the default resource estimate. That estimate is currently overridden by unrelated values inherited from the parent test action.
The behavior is also surprising operationally: increasing a test’s memory requirement can increase the time required to generate its JUnit report, even though XML generation consumes essentially no additional memory.
### Which category does this issue belong to?
Performance
### What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Consider a local test with deliberately large resource requirements:
```
sh_test(
name = "large_resource_test",
srcs = ["large_resource_test.sh"],
tags = [
"local",
"cpu:8",
"resources:memory:16384",
],
)
```
The test script completes successfully but does not write XML_OUTPUT_FILE:
```sh
#!/usr/bin/env bash
sleep 1
exit 0
```
Run it with other local tests and a bounded resource budget:
```sh
bazel test //... \
--nocache_test_results \
--local_resources=cpu=8 \
--local_resources=memory=16384 \
--profile=/tmp/profile.json
```
After large_resource_test finishes, Bazel creates the fallback XML-generation spawn. Although this helper only reads a log and writes a small XML file, its effective local resource request is also eight CPUs and 16 GiB.
If another action acquires any resources after the test exits, the XML helper cannot start. The profile can therefore show:
TestRunner process 1.0s
Acquiring resources for TestRunner 30.0s
XML-generation process <1s
The resource wait occurs after the actual test has completed and can substantially delay completion of the test action.
### Proposed fix
Construct the fallback XML spawn with execution information appropriate to the XML generator instead of passing the parent test’s complete execution-information map.
In particular, the XML spawn should not inherit:
- cpu:*
- resources:memory:*
- GPU requirements
- arbitrary custom-resource requirements
- other workload-specific resource estimates from the test target or its execution properties
### Which operating system are you running Bazel on?
_No response_
### What is the output of `bazel info release`?
9.2.0
Contributor guide
Research direction
Start in src/main/java/com/google/devtools/build/lib/exec/StandaloneTestStrategy.java at the fallback spawn construction around lines 474-487, then read SimpleSpawn.getLocalResources() around lines 241-253. Trace how execution information reaches the XML-generation spawn and verify that workload-specific CPU, memory, GPU, and custom-resource requirements are no longer inherited while the fallback report still completes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- build-system, testing
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 70/100