test.xml missing when running flaky test

[exoson]

Description of the bug:

When running a flaky test with the --flaky_test_attempts=10 and --remote_download_minimal flags with remote execution, bazel build execution will stop if the test fails with the following error message:
ERROR: /data/repos/test_repo/BUILD:9:8: Testing //:python_test failed: unexpected I/O exception: /home/ekattainen/.cache/bazel/_bazel_ekattainen/f465db4dd2df63e33090e2c00fda9ac6/execroot/main/bazel-out/k8-fastbuild/testlogs/python_test/test.xml -> /home/ekattainen/.cache/bazel/_bazel_ekattainen/f465db4dd2df63e33090e2c00fda9ac6/execroot/main/bazel-out/k8-fastbuild/testlogs/python_test/test_attempts/attempt_1.xml (No such file or directory)

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

Have a workspace with empty WORKSPACE file and BUILD and flaky_test.py files with following contents

$ cat BUILD
py_test(
    name = "flaky_test",
    srcs = "flaky_test.py",
)
$ cat flaky_test.py
import random
import sys

if random.random() > 0.5:
    sys.exit(1)

Run the following command until the test fails

$ bazel test //:python_test --nocache_test_results --config=remote_exec --flaky_test_attempts=4 --remote_download_minimal

The --config=remote_exec should configure bazel to execute the actions remotely.

Which operating system are you running Bazel on?

Ubuntu 20.04

What is the output of bazel info release?

development version

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

bazel build //src:bazel-bin

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

de02e3f62598dbe8dcff68b4040f34da3322c720
de02e3f62598dbe8dcff68b4040f34da3322c720

Have you found anything relevant by searching the web?

No response

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

The culprit for this bug seems to be #16123 Tagging @coeuvre as the PR author if he were to come up with a quick fix.

[coeuvre]

Thanks for the report. I am able to reproduce this locally.

The fix is fairly easy though: we just need to override renameTo method in RemoteActionFileSystem. I will wait until #16283 is submitted because it makes lots of changes to RemoteActionFileSystem.