jschoubben
49b1136ded
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
1.1 KiB
status, opened, located-in, fixed-by, amended-design
| status | opened | located-in | fixed-by | amended-design | ||
|---|---|---|---|---|---|---|
| open | 2026-09-30 |
|
167 — Code several modules share has no home
What was observed
The download-stack write-in step (register download clients and torznab indexers through the Servarr
API) is identical for sonarr, radarr, lidarr and bookshelf. Because a module builds from its own
directory, it now exists as four byte-identical copies under modules/<m>/downloads/, kept honest by a
test that fails when one differs. The same shape repeats: an MQTT probe copied into two modules, and a
"write the provider into the app through its API, idempotently, refuse a minted value" step in ombi,
home-assistant, nodered, tautulli and the four downloaders.
What would be right
A home for shared module code the builder can use — an sdk helper (a write-in step harness: read bindings and pair credentials, probe the provider, diff, write, report) or a shared package the catalogue builds once — so a fix lands in one place.