Trigger a Metrics Archive Run

Manually run the metrics-archiving job once, on demand.

This invokes the same code path as the scheduled MetricsArchiveScheduler run, so it respects all the same checks:

• Concurrency lock — if an archive run is already in progress (the JobScheduler lock is held, on this or another node), no new run is started and the response status is skipped_already_in_progress.
• Retention rules — moves metric rows older than retain_metrics_days to metricarchive, up to retain_metrics_move_limit rows; then deletes metricarchive rows older than retain_archive_metrics_days.
• Run log — the outcome is written to the metricsarchiverun audit log, exactly as a scheduled run would be.

Response fields:

• status — completed (a run executed — inspect run.success) or skipped_already_in_progress.
• message — human-readable summary.
• run — the recorded run (run id, counts, duration, success, remark); absent when skipped.
• in_progress — present only when skipped: the lock that blocked the run (job_id, api_instance_id, started_at, age_seconds). A large age_seconds (much older than a normal run) indicates a stale lock left by a dead JVM — clear the matching jobscheduler row to unblock.

Note: the run executes synchronously, so a large backlog may take a while.

User Authentication is Required. The User must be logged in. The Application must also be authenticated.