X_JOB_KEY_BUSY
Means
the concurrency key already holds its limit of runs
Typical cause
a job declaring concurrency: { key, limit, whenBusy: 'fail' } was claimed while limit runs under the same key were still in flight. The run settles failed without its body running, is not retried and is not dead-lettered — the declared answer to a second run of one key, never a fault. whenBusy: 'wait' (the default) leaves the run queued instead
Fix
x jobs list --name <job> --state running --json