## Problem/Motivation Two modules bind the vault-client contract, and they bind it by writing the same service name: - `pdv.services.yml:68` — `Drupal\pdv_client_api\VaultClientInterface: '@Drupal\pdv\LocalVaultClient'` - `modules/pdv_client/pdv_client.services.yml:42` — `Drupal\pdv_client_api\VaultClientInterface: '@Drupal\pdv_client\RemoteVaultClient'` Neither module conflicts with the other, so a site can have both — which is what a site part-way through moving its vault to another host has. On that site the winner is whichever module's service file loads last, and service files load in `core.extension` order: weight, then name. Nothing about which of the two a site meant to use comes into it. `pdv_client` sorts after `pdv`, so today the remote one wins. That is alphabetical luck rather than a decision, and a weight change or a rename would silently turn every vault call into a local one — writing personal data into the database of the site that was moved off it precisely so it would hold none. `pdv_client_api` also ships no `services.yml`, so the contract module does not declare its own service name. A module that depends on the contract alone therefore cannot inject `VaultClientInterface`: its container does not compile until an implementation happens to be installed. That is why `pdv_webform` reaches for the container at runtime in four places instead — - `modules/pdv_webform/src/PdvFileValueResolver.php:49` - `modules/pdv_webform/src/Element/PdvFile.php:339`, `:392`, `:401` — and `PdvFileValueResolver` is a plain class that could have been a service and injected if there had been a name to inject. There is also no answer for a site that has installed neither: nothing says so, and the first thing to ask for a vault finds out by failing. ## Proposed resolution The same shape kessai settled on in [#3621924] and [#3621925], where the problem was identical — one contract, a local engine and a remote client, and a YAML alias deciding between them by accident. **The contract module declares its own service name, and implementations announce themselves with a tag.** - `pdv_client_api` gains a `VaultClientResolver` and a `services.yml` that builds `Drupal\pdv_client_api\VaultClientInterface` from it. A consumer's container then compiles whether or not an implementation is installed. - `LocalVaultClient` and `RemoteVaultClient` each carry a `pdv_vault_client` tag with a priority instead of overwriting a name. The local one sits at the default; the client outranks it, because a site that installed the client installed it on purpose and an implementation still present beside it is one being removed. - Asking for a vault client on a site with no implementation raises a named exception saying so, and `hook_runtime_requirements` says it on the status report rather than leaving a user to find out mid-form. The priority is then the boundary rather than a side effect of module names, and it is written down where someone changing it will read it. **And `pdv_webform` injects.** `PdvFileValueResolver` becomes a service; the element's render callbacks are static and will keep asking the container, which is what core's own elements do, but they ask for a name the contract owns rather than one an implementation happens to have defined. ## Remaining tasks - `VaultClientResolver` + `services.yml` in `pdv_client_api`, and the exception it throws. - The tag and priorities on both implementations; delete both aliases. - `hook_runtime_requirements` for a site with no implementation. - `pdv_webform`: inject where injection is possible. - A kernel test that installs both implementations at once and asserts which one the contract resolves to. It is the one thing that cannot be checked by reading the code, because the answer comes out of a compiled container. ## User interface changes A status report entry on a site that has the contract and no implementation. ## API changes None to the contract itself. `Drupal\pdv_client_api\VaultClientInterface` goes on being the service name to ask for, and goes on answering the same interface; what changes is which module owns that name. ## Data model changes None. AI-Generated: Yes (Claude Code was used to help investigate and draft this issue summary.)