9.1.0rc1 adds new platform properties breaking remote execution

[meroton-benjamin]

Description of the bug:

The addition of:

#28710

Added logic that adds a platform property to remote execution calls to specify which remote persistent worker to use when running remote persistent workers. This breaks remote execution of existing environments as this key is unrecognized.

This has been detected as an issue in this ruleset.

bazel-contrib/rules_img#452

But probably exists in many more rulesets and codebases

Which category does this issue belong to?

Remote Execution

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

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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 ?

If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.

No response

Have you found anything relevant by searching the web?

No response

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

No response

[iancha1992]

@meroton-benjamin @psalaberria002 Could you please provide complete steps to reproduce this issue? Also, please provide output or logs when you execute.

[EdSchouten]

Bazel may fail to execute actions against a Buildbarn cluster, and will print an error message along with these lines:

java.io.IOException: io.grpc.StatusRuntimeException: FAILED_PRECONDITION: No workers exist for instance name prefix "..." platform {"properties":[...,{"name":"persistentWorkerProtocol","value":"json"}]}

Though there are some build cluster implementations out there that perform subset/superset matching of platform properties, there is absolutely no requirement in the REv2 spec that clusters should do this. As a result, Buildbarn's default is to do exact matching.

[iancha1992]

cc: @tjgq

[armandomontanez]

I'll send out a PR to ensure this property isn't set unless remote persistent workers are enabled. RE services that support remote persistent workers need the signal to produce correct actions, but when remote persistent workers are not enabled it's entirely unnecessary.

[fmeum]

Due to https://github.com/bazelbuild/remote-apis/blob/main/build%2Fbazel%2Fremote%2Fexecution%2Fv2%2Fremote_execution.proto#L870, this would always be an incompatible change. Could this be gated behind GetCapabilities? If not, perhaps it would be better to roll it back for 9.1.0 and wait for Bazel 10?