[frekw]

This PR was written primarily by Claude Code (Claude Opus 5.5). I reviewed the change and its tests before opening it.

Related: #21409, #21918.

Problem

Enabling Python and Java or Scala protobuf codegen together registers two resolve-like fields on protobuf_source: python_resolve and jvm_resolve. Protobuf dependency inference then fails on every proto with:

NotImplementedError: TODO: Multiple resolve-like fields on target at address `protos/a.proto`.

map_protobuf_files already handles this. A target with two resolve-like fields goes into one partition per field. Only the lookup side, get_resolve_key_from_target, gives up.

A second bug sits in the same lookup. If any partition is the "resolves disabled" sentinel, every target uses the sentinel partition. With Python resolves disabled and JVM resolves enabled, inference ignores jvm_resolve entirely, so jvm_resolve=parametrize("j1", "j2") makes every import ambiguous and infers nothing.

Solution

get_resolve_keys_from_target returns one key per resolve-like field on the target, with the sentinel for a field whose resolves are disabled. For each import, inference takes the owners the import has in each of those resolves and intersects them:

• One owner left: infer it.
• Several left: the usual ambiguity warning and disambiguation, over the intersection.
• None left: nothing, as when the import has no owner in a single resolve today.

With one resolve-like field this is exactly today's behaviour. With two, it picks the owner that shares every one of the importing target's resolves. That is the only owner the target can build against in each language. For protobuf_source(python_resolve=parametrize("a", "b"), jvm_resolve=parametrize("j1", "j2")), each import has two owners per resolve but exactly one in the intersection, the variant with the same parameters.

The shortcut to the sentinel partition now applies only when the mapping has no other partitions, which is what it was for.

Design note

I considered inferring per language instead: the Python resolve when Python consumes the proto, the JVM resolve when Java or Scala does. That would be in the spirit of #23668's per-requesting-language dispatch. But dependency inference produces one dependency set per target, with no requesting language to consult, so the intersection is what that set can express. If the maintainers would rather discuss this in an issue first, I'm happy to move it there.

Testing

Three new tests in protobuf_dependency_inference_test.py use the real PythonResolveField and PrefixedJvmResolveField, registered the way the Python, Java and Scala backends register them:

• both fields set (raised NotImplementedError on main)
• both fields parametrized (raised NotImplementedError on main)
• Python resolves disabled, jvm_resolve parametrized (silently inferred nothing on main)

The parametrized cases use per-file protobuf_source targets because jvm_resolve is registered as a copied field on protobuf_sources, so it can't be parametrized there yet. That is a separate one-line change.

The existing protobuf and Python-protobuf inference tests pass unchanged.

🤖 Generated with Claude Code

[tdyas]

Looks good to me. Thanks for fixing!