Files
Bose-SoundTouch/pkg
Tobias GesellchenandClaude Opus 5 1a56b184dc fix(setup): don't offer a telnet revert on speakers that were never migrated
telnetRevertAvailable compared the live URLs against canonicalBoseTelnetURLs
and reported "revertable" on any difference. That set is one original variant,
not the only one: this repo's own model of a factory speaker
(pkg/service/testing/fakespeaker) uses stats.bose.com and bmxservice.bose.com
where the canonical set has events.api.bosecm.com and content.api.bose.io.

Feeding that fixture to the gate returned true, so the web UI offered
"Restore Bose URLs via Telnet" on a pristine speaker. Pressing it rewrites the
device's genuine factory URLs and commits them through envswitch, the layer
that wins on the next reboot. The speaker keeps working, since both host sets
point at the shut-down Bose cloud, but the record of what that device's URLs
actually were is gone, and telnet migration takes no backup to recover it from.

The question the gate should answer is "has this been changed away from a
factory configuration", not "does it differ from our canonical set". It now
compares each field against the values observed on unmigrated speakers,
normalising case and a trailing slash so firmware echoing does not decide it.

Only observed values are listed. Other Bose hostnames appear in the DNS
interception lists and in DNS recordings, but those capture hosts a speaker
resolves at runtime rather than the configured value of these four fields, and
a wrong entry would hide the revert from someone who needs it.

The existing test could not catch this: it asserts against the same canonical
constants the code was comparing with.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-05 22:32:50 +02:00
..