hermes - 💡(How to fix) Fix Expose currently-running cron jobs via /api/jobs (or new endpoint) [1 pull requests]

Ask

Surface which cron jobs are executing right now through the public HTTP API. Either:

• enrich each record in GET /api/jobs with is_running: bool (and optionally current_session_id/current_started_at), or
• add GET /api/jobs/active returning { job_id, session_id, started_at }[].

Background

The data exists internally but is unreachable from any HTTP client:

• cron/scheduler.py creates _cron_session_id = f\"cron_{job_id}_{timestamp}\" per run, opens a SessionDB row, and calls end_session(_cron_session_id, \"cron_complete\") only on completion.
• state.db sessions table therefore contains a perfectly reliable signal: id LIKE 'cron_%' AND ended_at IS NULL ⇒ active cron run.
• gateway/platforms/api_server.py:_handle_list_jobs returns raw _cron_list() records. The state field there only ever cycles scheduled | paused | completed — it is never set to running during execution. There is no /api/sessions, no /api/jobs/active, no enrichment.

Net effect for downstream UIs: there is no supported way to display "this cron job is currently running" without reading the SessionDB SQLite file directly (which couples the UI to internal schema and breaks across profile paths and remote deployments).

Repro

1. Trigger a long-running cron via POST /api/jobs/{id}/run.
2. Poll GET /api/jobs/{id} while it executes.
3. Observe state stays \"scheduled\"; no field indicates the run is in flight. last_run_at only updates after completion.

Meanwhile sqlite3 ~/.hermes/profiles/<profile>/state.db 'SELECT id FROM sessions WHERE id LIKE \"cron_%\" AND ended_at IS NULL' shows the active session correctly.

Suggested shapes

Option A — enrich existing endpoint (minimal change): ```jsonc // GET /api/jobs { "jobs": [ { "id": "aa845838ceb1", "name": "...", "state": "scheduled", "is_running": true, "current_session_id": "cron_aa845838ceb1_20260528_095452", "current_started_at": "2026-05-28T09:54:52+02:00" } ] } ```

Option B — dedicated endpoint: ``` GET /api/jobs/active → 200 [ { "job_id": "aa845838ceb1", "session_id": "cron_aa845838ceb1_...", "started_at": "2026-05-28T09:54:52+02:00" } ] ```

Why API, not direct DB read

There is precedent for keeping internal storage internal. Interstellar-code/hermes-agent #16 (CLOSED) handled the identical situation for workflow-engine node runs by adding GET /api/plugins/workflow-engine/node-runs/active, which allowed the downstream UI to delete its split-brain SQLite mirror. Cron should follow the same model.

Impact

Without this, any UI showing a "running" indicator for cron jobs (status pill, filter, badge, Matrix3D presence) is forced into one of:

1. Direct read of state.db (fragile, breaks remote/Docker, couples to schema).
2. Lying — never showing a running state.
3. Heuristics on last_run_at / next_run_at (always wrong for long-running jobs).

Refs

• Internal session id convention: cron/scheduler.py:1205
• End marker: cron/scheduler.py:1642 (end_session(..., \"cron_complete\"))
• Current list endpoint with no enrichment: gateway/platforms/api_server.py:_handle_list_jobs (~line 2434)
• Precedent: Interstellar-code/hermes-agent#16