Aller au contenu
login
arrow_backRetour aux issues
atomantic/PortOS #4850

Retire the overlap-release acceptsLyrics field once no supported peer reads it

ecoDébutant good first issue plan area:media model:light effort:low

descriptionDescription

## Problem #4826 moved the "does this build carry lyrics on the wire" probe from the per-capability `capability.acceptsLyrics` boolean to a status-root `features: string[]` list. The old field is still emitted, deliberately, so a consumer running the pre-#4826 build keeps working through the overlap release. Once no supported peer reads the legacy field, it should go. Leaving it indefinitely re-establishes the two-spellings problem #4826 removed: a future reader sees a capability field that looks live but is only a compatibility shim. ## What to do Remove the field and its fallback. Every read already funnels through one helper on each side, so this is a small, contained deletion: - `server/lib/federatedMediaWire.js` — drop `acceptsLyrics` from `federatedMediaCapabilitySchema`, and drop the `lyrics` entry from `FEDERATED_MEDIA_LEGACY_FEATURE_TELL` - `server/services/federatedMediaProvider.js` — stop emitting `acceptsLyrics` at both capability sites (`configuredAudioCapabilities`, `localGeneratorCapabilities`) - `client/src/lib/federatedMediaReadiness.js` — drop the `lyrics` entry from `LEGACY_FEATURE_TELL` - `docs/FEDERATED_MEDIA_PROVIDERS.md` — drop the `acceptsLyrics` row from the lyrics signal table and the retirement note in the `features` section - Tests: `server/lib/federatedMediaWire.test.js`, `server/routes/music.test.js`, `server/services/federatedMediaProvider.test.js`, `client/src/lib/federatedMediaReadiness.test.js`, `client/src/components/music/MusicGenPanel.test.jsx` all carry legacy-path cases that go with it. Keep every `features`-path case. The `inputAssets` legacy tell (capability block presence) stays — it is not a shim, it is the only signal a mid-overlap peer sends, and it is genuinely per-model besides. ## Blocked until The release carrying #4826 has shipped and installs have had a reasonable window to update. Verify no supported peer still depends on the field before removing it — a consumer that has not updated will silently degrade every remote lyrical render to instrumental, which is exactly the failure the field was added to prevent. Refs #4826
codeOuvre sur GitHub