#23649 pantsd constrains plugin resolves to the version it already resolved, so changing [GLOBAL] plugins fails until the daemon restarts Issue created by jasonwbarnett Describe the bug Once

pantsd

has resolved a pinned

[GLOBAL] plugins

entry, every later plugin resolve in that daemon process is constrained to the version it already resolved. Bumping the pin then fails:

ProcessExecutionFailure: Process 'Resolving plugins: botocore==1.43.74' failed with exit code 1.
pip: ERROR: ResolutionImpossible
pip:      The user requested botocore==1.43.74
pip:      The user requested (constraint) botocore==1.43.73

1.43.73

is no longer anywhere in the config — only the running daemon still knows about it. Running the identical command a second time passes: the exception trips `pantsd`'s kill switch, so the daemon dies and the next invocation starts clean. Reproduction https://github.com/altana-ai/pants-pantsd-stale-plugin-resolve —

./repro.sh

. Needs only the

pants

launcher and PyPI. Cause 1.

PluginResolver.resolve

builds

PluginsRequest.constraints

from

find_matching_distributions(None)

— every distribution active on the current

sys.path

(

src/python/pants/init/plugin_resolver.py

). 2. The same method then `site.addsitedir`s the resolved plugin onto that

sys.path

, as its own docstring notes: "the system enviroment on

sys.path

will be mutated by each call to `PluginResolver.resolve`". 3.

PantsDaemonCore.prepare

calls

build_config

— and so

resolve

— on every run inside the long-lived daemon process, and

_initialize_build_configuration

is not memoized. 4. A changed

plugins

value only produces

Initialization options changed … Reinitializing scheduler

. The scheduler is rebuilt; the process is not, so the mutated

sys.path

survives. So run N's plugin version becomes a hard constraint on run N+1. The resolve is constrained by state it created itself, which no user config can express. Impact On reused (non-ephemeral) CI agents this is worse than a single failure. It is symmetric — a branch that has not yet rebased past a bump fails against a bumped daemon exactly as a bumped branch fails against a stale one — and it is intermittent, because the retry passes. A bot bumping a pinned plugin (Renovate does this for

botocore

, which

pants.backend.url_handlers.s3

requires) therefore destabilises a whole fleet for as long as both versions are in flight, and repeatedly ejects PRs from a merge queue instead of failing them cleanly. Possible fixes • Restart the daemon when

plugins

changes, rather than only reinitializing the scheduler. • Or exclude previously-resolved plugin distributions from the inherited constraint set. • Or skip inherited constraints for a requirement that is already an exact pin. Workaround in the meantime: kill

pantsd

for that build root when the checked-out

plugins

value differs from the one the running daemon resolved. Pants version 2.33.0 (scie-pants 0.13.2) OS Reproduced on Ubuntu 24.04 and Amazon Linux 2023, both x86_64. pantsbuild/pants