Files
hq/04-ISSUES/165-one-accepted-value-must-be-accepted-once-per-consumer/00-report.md
T
jschoubben 49b1136ded Issues 164-168: found provisioning every dependency on ace
164 a credential that must be accepted is minted anyway
165 one accepted value must be accepted once per consumer
166 a requirement cannot be optional
167 code several modules share has no home
168 a setting reaches every file and every contribution
2026-09-30 13:28:53 +02:00

25 lines
1023 B
Markdown

---
status: open
opened: 2026-09-30
located-in:
- mesh-controller internal/inventory/secrets.go (AcceptSecretForPair is per consumer)
fixed-by:
amended-design:
---
# 165 — One accepted value must be accepted once per consumer
## What was observed
On ace, jackett's API key is the pair credential for sonarr, radarr, lidarr and bookshelf; sonarr's is
the credential for ombi, bazarr and home-assistant. It is **one value**, owned by the provider — yet
`secret accept` is per pair, so ace's download stack alone needs 12 accepts of 3 values, and rotating
a provider's key means finding and re-accepting every pair. Missing one leaves that consumer on a
stale (or minted, 164) value.
## What would be right
A provider-level accept: "this provider's credential for `<provision>` is X" — delivered to every
consumer pair, current and future, and rotated in one place. Pairs whose credential is genuinely per
consumer (postgres, keycloak, mosquitto, influxdb — minted and created by a provisioner) are unaffected.