run-template:get fails with "The 'fields' option does not exist"

[Vitexus]

Description

The run-template:get command fails with an internal error regardless of the --format option used.

Steps to Reproduce

multiflexi-cli run-template:get --id=186
multiflexi-cli run-template:get --id=186 --format=json
multiflexi-cli run-template:get --id=186 --format=text

Actual Output

                                       
  The "fields" option does not exist.  
                                       

run-template:get [-f|--format [FORMAT]] [--id ID] [--name NAME]

Exit code: 1

Expected Output

Details of the run template with ID 186 (or any valid ID) in the requested format.

Environment

• multiflexi-cli version: 2.5.2.222 (ii multiflexi-cli 2.5.2.222~bookworm all)
• OS: Debian Bookworm
• PHP: 8.2.29

Notes

run-template:list works correctly and shows the run template with ID 186 in the output, so the record exists in the database. The issue is specific to run-template:get.

[Vitexus]

Additional evidence with --format=json

run-template:get also fails with --format=json:

$ multiflexi-cli run-template:get --id=186 --format=json

  The "fields" option does not exist.  

run-template:get [-f|--format [FORMAT]] [--id ID] [--name NAME]

As a workaround, the record can be retrieved via run-template:list --format=json and filtered client-side:

$ multiflexi-cli run-template:list --format=json | python3 -c \
  'import sys,json; data=json.load(sys.stdin); [print(json.dumps(r,indent=2)) for r in data if r["id"]==186]'

Output:

{
  "id": 186,
  "app_id": 19,
  "company_id": 1,
  "interv": "d",
  "prepared": null,
  "success": "a:7:{s:6:\"Zabbix\";b:1;s:10:\"Reschedule\";b:0;s:4:\"Stop\";b:0;s:5:\"Sleep\";b:0;s:9:\"LaunchJob\";b:0;s:7:\"WebHook\";b:0;s:13:\"CustomCommand\";b:0;}",
  "fail": "a:7:{s:6:\"Zabbix\";b:1;s:10:\"Reschedule\";b:0;s:4:\"Stop\";b:0;s:5:\"Sleep\";b:0;s:9:\"LaunchJob\";b:0;s:7:\"WebHook\";b:0;s:13:\"CustomCommand\";b:0;}",
  "name": "DRE RAF2 CZK - 5230011111 Výpisy do Pohody ",
  "delay": 18720,
  "executor": "Native",
  "active": 1,
  "cron": "0 0 * * *",
  "last_schedule": "2026-05-17 05:12:00",
  "next_schedule": "2026-05-19 12:32:15",
  "note": null,
  "DatCreate": "2025-11-13 16:37:56",
  "DatSave": "2026-05-19 12:33:19",
  "successfull_jobs_count": 209,
  "failed_jobs_count": 16,
  "app_uuid": "e9893573-24aa-4518-bf05-66fae9ad153c"
}

So the data is there and the list command works fine — the issue is isolated to the get subcommand's internal handling.

[Vitexus]

Root cause investigation (follow-up)

While investigating why run-template #186 had a stale next_schedule in the past and no job was running, we hit the run-template:get bug and had to work around it. This surfaced a related but separate issue worth documenting here.

What we found

run-template:get was needed to inspect a run-template whose next_schedule was stuck in the past (2026-05-19 12:32:15) with no corresponding entry in the queue. The job had not run for over a day despite active=1 and a valid cron schedule.

The root cause was an orphaned job (id=85326):

• begin: 2026-05-18 15:35:12
• end: NULL
• exitcode: NULL
• pid: NULL
• schedule_type: adhoc

The job was launched but never finished (executor restart or SIGKILL mid-run), leaving next_schedule pointing to a queue slot that no longer existed. The scheduler did not self-correct because both multiflexi-scheduler and multiflexi-executor had just been restarted.

Resolution

$ multiflexi-cli queue:fix --format=json
{
    "status": "success",
    "messages": [
        { "type": "debug", "message": "Reset next_schedule for runtemplate #186 - missing job in queue" },
        { "type": "debug", "message": "Reset next_schedule for runtemplate #228 - missing job in queue" }
    ]
}

Then manually rescheduled:

$ multiflexi-cli run-template:schedule --id=186 --schedule_time=now --format=json
{
    "runtemplate_id": "186",
    "scheduled": "2026-05-20 14:53:06",
    "executor": "Native",
    "job_id": 85861
}

Job 85861 completed successfully (exit 0) — downloaded and uploaded the bank statement PDF+XML to SharePoint.

Why run-template:get matters here

During this investigation we could not use run-template:get --id=186 to quickly inspect the template state. We had to fall back to run-template:list --format=json and filter client-side, which is cumbersome. A working run-template:get would have made the diagnosis significantly faster.