`Desugar` actions don't run on multiplex workers

[lukaciko]

Desugar action runs on a singleplex workers even when --persistent_multiplex_android_dex_desugar is set.

rules/desugar.bzl hardcodes execution_requirements = {"supports-workers": "1"} — it never checks persistent_multiplex_android_dex_desugar, so the --persistent_multiplex_android_dex_desugar flag has no effect on Desugar actions. This is apparently a Starlark migration regression. rules/dex.bzl does this correctly for DexBuilder.

Fixing this issue on the Spotify app brought down Desugar's critical path contribution from 60s to 7s on our API change scenario.

Fix

Mirror what dex.bzl already does:

execution_requirements = {}
if ctx.fragments.android.persistent_android_dex_desugar:
    execution_requirements["supports-workers"] = "1"
    if ctx.fragments.android.persistent_multiplex_android_dex_desugar:
        execution_requirements["supports-multiplex-workers"] = "1"

Everything else is already wired — the flag expands correctly (bazel canonicalize-flags shows --internal_persistent_multiplex_android_dex_desugar=1), AndroidConfigurationApi exposes the field to Starlark, and the Desugar tool uses WorkRequestHandler which supports multiplex.

Confirmed still present in v0.7.3. Tested against v0.7.1 / Bazel 8.6.0.

[lukaciko]

Hmm, there might be more to the story. We set --noworker_sandboxing and don't set --experimental_worker_multiplex_sandboxing.. I think that also affects if the Desugar is run with multiplex workers.

[ted-xie]

We recently started moving some of this functionality around. I think there's a pending internal change (TL;DR a big pile of flags in bazelrc) to fix this.