@pierre-gilles, Claude me dice que el problema viene del core. Aquí está su análisis. Podrás echar un vistazo
El diagnóstico
Cuando el front envía el dispositivo descubierto en POST /api/v1/device, no envía ningún selector. El core lo genera entonces en un hook Sequelize beforeValidate:
server/utils/addSelector.js:11-17
function addSelector(item) {
if (item.selector) {
item.selector = slugify(item.selector);
} else if (item.name) {
item.selector = slugify(item.name); // <-- aquí
}
}
Por lo tanto, selector = slugify(device.name), sin ningún desdoblamiento, aunque la columna es unique: true (server/models/device.js:32-36). La restricción UNIQUE salta, Sequelize lanza un SequelizeUniqueConstraintError, y errorMiddleware.js:42-49 lo transforma en 409 en el atributo selector — exactamente lo que ve el miembro del foro.
Su dispositivo Spotify Connect se llama « MacBook Pro de … » → selector macbook-pro-de-..., que ya existe en su caso (probablemente otro dispositivo con el mismo nombre: un Chromecast, un AirPlay, un dispositivo de otra integración, o un Spotify ya añadido y luego renombrado).
Lo que esto implica
El problema no está en el plugin de Spotify: nuestros external_id son únicos (ext:<selector-integración>:spotify:<deviceId>), el external_id del dispositivo de Spotify nunca entra en colisión. Es una limitación del core: el selector se deriva del nombre, y dos dispositivos con el mismo nombre son imposibles de crear.
Hay que señalar que el core ya sabe hacer mejor esto en otro lugar — externalIntegration.buildSelector.js:25 hace un bucle para encontrar un candidato libre:
while ((await db.Service.findOne({ where: { selector: candidate } })) !== null) {
Esta lógica simplemente nunca se ha aplicado a los dispositivos.
