Spotify external integration: having a unique selector

Hello it’s me!!
I can access the external plugin :slight_smile:
I wanted to integrate Spotify:


Is there no way to have a single selector (uuid)?

I’ll take a look

@pierre-gilles, Claude says the problem is with the core. Here’s his analysis. You can take a look

The Diagnosis

When the front POSTs the discovered device to /api/v1/device, it doesn't send a selector. The core then generates it in a Sequelize beforeValidate hook:

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);   // <-- here
  }
}

So selector = slugify(device.name), without any deduplication, even though the column is unique: true (server/models/device.js:32-36). The UNIQUE constraint is skipped, Sequelize throws a SequelizeUniqueConstraintError, and errorMiddleware.js:42-49 turns it into a 409 on the selector attribute — exactly what the forum member sees.

His Spotify Connect device is named « MacBook Pro de … » → selector macbook-pro-de-..., which already exists for him (probably another device with the same name: a Chromecast, an AirPlay, a device from another integration, or a previously added and renamed Spotify).

What This Implies

The problem isn't in the Spotify plugin: our external_id are unique (ext:<selector-integration>:spotify:<deviceId>), the Spotify device's external_id never collides. This is a core limitation: the selector is derived from the name, and two devices with the same name cannot be created.

Note that the core already does better elsewhere — externalIntegration.buildSelector.js:25 loops to find a free candidate:
while ((await db.Service.findOne({ where: { selector: candidate } })) !== null) {
This logic has simply never been applied to devices.

@Will_71 You’re right, we should handle this case :slight_smile: I’ll handle it in a PR

It’s fixed here:

The fix is live in 4.84.4: