Hello c’est moi !!
J’ai donc bien acces au plugin externe ![]()
J’ai voulus intégré spotify :
Aucun moyen d’avoir un selecteur unique (uuid) ?
Hello c’est moi !!
J’ai donc bien acces au plugin externe ![]()
J’ai voulus intégré spotify :
Aucun moyen d’avoir un selecteur unique (uuid) ?
Je vais regarder
@pierre-gilles, Claude me dit que le problème vient du core voilà son analyse. Tu pourras regarder
Le diagnostic
Quand le front POST le device découvert sur /api/v1/device, il n'envoie pas de selector. Le core le génère alors dans 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); // <-- ici
}
}
Donc selector = slugify(device.name), sans aucun dédoublonnage, alors que la colonne est unique: true (server/models/device.js:32-36). La contrainte UNIQUE saute, Sequelize lève un SequelizeUniqueConstraintError, et errorMiddleware.js:42-49 le transforme en 409 sur l'attribut selector — exactement ce que voit le membre du forum.
Son appareil Spotify Connect s'appelle « MacBook Pro de … » → selector macbook-pro-de-..., qui existe déjà chez lui (probablement un autre appareil du même nom : un Chromecast, un AirPlay, un device d'une autre intégration, ou un Spotify déjà ajouté puis renommé).
Ce que ça implique
Le problème n'est pas dans le plugin Spotify : nos external_id sont bien uniques (ext:<selector-integration>:spotify:<deviceId>), l'external_id du device Spotify n'entre jamais en collision. C'est bien une limite du core : le selector est dérivé du nom, et deux appareils portant le même nom sont impossibles à créer.
À noter que le core sait déjà faire mieux ailleurs — externalIntegration.buildSelector.js:25 boucle justement pour trouver un candidat libre :
while ((await db.Service.findOne({ where: { selector: candidate } })) !== null) {
Cette logique n'a simplement jamais été appliquée aux devices.
@Will_71 Tu as raison, on devrait gérer ce cas
Je gère ça dans une PR
C’est corrigé ici :
Le correctif est live dans la 4.84.4 :