Basic Job failing with "Invalid parameters" Error on vm.start

[techjeffharris]

It looks like the API wants the IDs of the vms to be sent as a String, but its getting an Array.

The Job is really simple -- just trying to start a single vm and giving a 60 second timeout. The configured timeout doesn't seem to matter. I have left timeout undefined, I have set it to 10 seconds, 15 seconds, and most recently 60 seconds.

On master branch @ ae549e2.

vm.start
{
  "host": [],
  "id": [
    "37adf020-3f5e-b9c9-c991-c2e7b2faa398"
  ]
}
{
  "code": 10,
  "data": {
    "errors": [
      {
        "code": null,
        "reason": "type",
        "message": "must be string, but is array",
        "property": "@.host"
      },
      {
        "code": null,
        "reason": "type",
        "message": "must be string, but is array",
        "property": "@.id"
      }
    ]
  },
  "message": "invalid parameters",
  "name": "XoError",
  "stack": "XoError: invalid parameters
    at Module.invalidParameters (/opt/xo/xo-builds/xen-orchestra-202111061328/packages/xo-common/src/api-errors.js:21:32)
    at Object.call (file:///opt/xo/xo-builds/xen-orchestra-202111061328/packages/xo-server/src/xo-mixins/api.mjs:73:18)
    at Api.callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202111061328/packages/xo-server/src/xo-mixins/api.mjs:300:19)"
}

[techjeffharris]

I would also like to note that I have a startup job that was configured some time ago (didn't document when) which works just fine. If I recreate the same job from scratch, I get this new error.

This suggests that the issue is realted to the newly created job object and the previous job object is still sending a string value containing the one VM rather than an array with a single vm.

It seems that either the UI changed to allow selection of multiple VMs per job, or if that was already possible, then the UI is attempting to send an array rather building a comma-separated string for example.

[pdonias]

Hi, thanks, we're working on it. If you need to fix your jobs, you can revert to this commit in the meantime: 84dccd8.

[techjeffharris]

Hi, thanks, we're working on it. If you need to fix your jobs, you can revert to this commit in the meantime: 84dccd8.

Thank you for providing that commit! I had been meaning to refresh my skills with git bisect, but haven't gotten around to it.

[techjeffharris]

Hi @pdonias -- sorry for the late response, but I am still seeing this issue after having reverted to commit 84dccd8.

[techjeffharris]

@pdonias

Just ran another test after updating to latest commit 686e7.

Created brand new start job with a single vm that is powered down, but got this error. Started the VM, created a brand new stop job with a single VM and it also failed with the same error (I only included one of the errors because aside from the ID, they are identical).

vm.stop
{
  "id": [
    "d86d61b9-daa5-1ad4-b085-e852adc123b3"
  ]
}
{
  "code": 10,
  "data": {
    "errors": [
      {
        "code": null,
        "reason": "type",
        "message": "must be string, but is array",
        "property": "@.id"
      }
    ]
  },
  "message": "invalid parameters",
  "name": "XoError",
  "stack": "XoError: invalid parameters
    at Module.invalidParameters (/opt/xo/xo-builds/xen-orchestra-202203010923/packages/xo-common/src/api-errors.js:21:32)
    at Object.call (file:///opt/xo/xo-builds/xen-orchestra-202203010923/packages/xo-server/src/xo-mixins/api.mjs:73:18)
    at Api.callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202203010923/packages/xo-server/src/xo-mixins/api.mjs:303:19)"
}

[techjeffharris]

Hey @pdonias. A couple of weeks ago, I updated to the latest commit at the time (commit f5b7c ) which brought me up to release 5.69.1.

Today, I created brand new start and stop jobs for a VM and they both worked as expected with no errors!

Now that I've seen it once, I'm going to enable my rules to automatically start/stop a few VMs that I don't need running all night long and if the issue returns, I'll let you know.

Thanks for all of your hard work on this project!

[olivierlambert]

Should we close it then?

[pdonias]

Yes, this should be closed. For the record, the original issue was there, we tried to fix it with this commit but it broke something else so we reverted it here and the original issue needs more investigation to be fixed.