Synchronise with netbox fails when pool name already exists in a different cluster type

[bokkepoot]

Upon importing information from XO towards netbox, the plugin test works as expected.

However, if the name of the pool is already taken (maybe if the slug is taken, unknown), for instance as a name in a different cluster type, it will fail.

Context

• XO origin: from source
• Versions:
  • Node: v14.17.1
  • xo-web: 5.83.0
  • xo-server: 5.79.6

Expected behavior

Failure message describing the issue

Current behavior

Error 400

netbox.synchronize
{
  "pools": [
    "96fb7dc7-f265-5a2c-8e4e-dde30d722dbf"
  ]
}
{
  "code": 400,
  "url": "https://netbox.protagio.org/api/virtualization/clusters/",
  "message": "Bad Request",
  "name": "Error",
  "stack": "Error: Bad Request
    at onResponse (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/http-request-plus/index.js:243:21)
    at AsyncResource.runInAsyncScope (async_hooks.js:197:9)
    at cb (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/util.js:355:42)
    at tryCatcher (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/promise.js:729:18)
    at _drainQueueStep (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/opt/xo/xo-builds/xen-orchestra-202106252210/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:464:21)
    at process.topLevelDomainCallback (domain.js:147:15)
    at process.callbackTrampoline (internal/async_hooks.js:129:24)"
} 

[pdonias]

Hi, thanks for the report. What behavior would you expect in that case? Also, do you have a use case for already having a cluster with the same name?

[bokkepoot]

I don't have a use case for having the same name/slug already being used. (it was actually an obsolete config)

However, if possible, an error message with an indication what actually goes wrong would be appreciated.

[pdonias]

Ok, we'll try to improve error messages on specific cases like this one. Thanks!