jochen
623fccee23
The operator asked on 2026-10-08 for the deprecated issues to be gone. In hq an issue is closed, never deleted, so each one is resolved with its fix, closed wontfix with a reason, or re-checked against main and the live mesh.
1.2 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.
Re-checked 2026-10-08: still holds. The media catalogue still carries the download-stack write-in step
as four copies, one under each of the four downloaders' downloads/.