Dashboard-triggered cross-server migrations fail with 1703 - same deployment works from OttoDeploy

Hi everyone,

I’m experiencing a consistent issue where migrations triggered from the api
fail, while the exact same deployment works perfectly when triggered from OttoDeploy directly.

Setup:

  • Source server: digimidi.fmcloud.fm — OttoFMS 4.16.2, FMS 22.0.2
  • Destination server: vetmidi.fmcloud.fm — OttoFMS 4.16.0, FMS 22.0.4
  • Same-server deployments (digimidi → digimidi) work fine from both OttoDeploy and the dashboard

What happens: The deployment fails immediately at the building phase (within ~7 seconds), before the JIT build even starts on the source server.

Error message:

Build server error: Error validating token: Local Admin API error: 
Fetch failed: Unauthorized code: 1703 - Invalid username or password, 
or JSON Web Token; Path: /fmi/admin/api/v2/server/metadata

What I’ve already checked:

  • The OttoFMS API key configured in the deployment (source server auth) is correct and valid
  • The OCC dashboard has the destination server (vetmidi) registered with a valid Admin API key
  • The deployment runs successfully when triggered from OttoDeploy on digimidi

Key observations:

  • The error occurs on the source server (digimidi) when it tries to call its own local FMS Admin API
  • There is a version mismatch between the two servers (4.16.0 vs 4.16.2) — could this affect how the JIT build token is validated when the request comes through OCC?
  • The same API key works fine when the request originates from OttoDeploy but fails when it comes through the OCC dashboard

Has anyone seen this behavior? Is there something specific that needs to be configured on the source server to accept JIT build requests initiated via the OCC dashboard?

Thanks

debug-logs-168.zip (17.3 KB)

Hey @antoine1162 ,

OttoFMS is using stored credentials to make calls to the Admin API. There is no difference between deployments from the Cloud Console and OttoDeploy other than what triggers them. If there was a problem with the Admin API Key you would either not be able to start the deployment at all or the call to start the build would fail immediately instead of having a separate log in the build logs.

I can’t be sure what is happening in your case as it looks like you sent the debug logs for a successful deployment and not the one that failed. I do see a number of logs in the logs you sent that the admin api is hanging, you may want to simply try restarting the admin api service on source and destination servers.

How are you starting the deployments from the OCC dashboard?

-Kyle