[Bug]: Matrix manual cron delivery fails with "Timeout context manager should be used inside a task"

[Bounz]

Bug Description

Manual cron job runs triggered from a live Matrix gateway session can fail during Matrix delivery:

Matrix: failed to send to !room: Timeout context manager should be used inside a task
cron.scheduler: Job '<job_id>': delivery error: Matrix send failed: Timeout context manager should be used inside a task

The job itself completes (last_status: ok); only the final Matrix delivery fails. Normal Matrix replies from the gateway continue to work.

Steps to Reproduce

1. Run Hermes Gateway with Matrix connected.
2. Create a cron job with deliver: "origin" or a Matrix target.
3. From a Matrix chat, manually trigger the job via cronjob(action="run") / manual cron run.
4. Observe Matrix delivery failing with Timeout context manager should be used inside a task.

Expected Behavior

Manual cron runs from Matrix should deliver through the same event-loop-safe live adapter path as scheduled in-gateway cron ticks.

Actual Behavior

Observed log example:

ERROR hermes_plugins.matrix_platform.adapter: Matrix: failed to send to !dbDMkhSyaccmgAoXgy:domain.tld: Timeout context manager should be used inside a task
ERROR cron.scheduler: Job '5e8ef31933f8': delivery error: Matrix send failed: Timeout context manager should be used inside a task

Affected Component

Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

No response

Debug Report

https://paste.rs/qpAdw

Operating System

Ubuntu 24.0.4.4

Python Version

3.11.15

Hermes Version

0.18.2

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

Manual cron delivery can reach this path:

cronjob(action="run")
  -> cron.scheduler._deliver_result(..., adapters=None, loop=None)
  -> tools.send_message_tool._send_to_platform(...)
  -> tools.send_message_tool._send_via_adapter(...)
  -> runner.adapters.get(matrix)
  -> await adapter.send(...)

The Matrix adapter owns a live mautrix/aiohttp client created on the gateway event loop. Calling adapter.send() directly from a different loop/task context makes aiohttp raise:

Timeout context manager should be used inside a task

cron/scheduler.py::_deliver_result() already schedules live-adapter delivery onto the gateway loop when it receives adapters and loop; the manual/tool path through send_message_tool._send_via_adapter() appears to bypass that safety.

Proposed Fix (optional)

Make tools/send_message_tool.py::_send_via_adapter() event-loop aware:

• when using a live gateway adapter, schedule adapter.send(...) onto the gateway loop via safe_schedule_threadsafe(...) instead of awaiting it directly from the caller loop;
• if no gateway loop is available, use standalone_sender_fn only when safe;
• for Matrix/E2EE, avoid silently downgrading to unencrypted raw HTTP delivery when encryption is required.

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[GottZ]

Two open PRs currently address or reference this issue. Summary of what each diff actually does:

• fix(cron): deliver manual runs on gateway loop #63586 (+49/-1) — fixes the root cause: passes the gateway adapter map and gateway loop via a runner weakref through tools/cronjob_tools.py::_execute_job_now into run_one_job(job, adapters=..., loop=...), so cron/scheduler.py::_deliver_result uses its existing loop-safe live-adapter path (runtime_adapter = (adapters or {}).get(platform), scheduler.py:1581) — exactly the cause described in the issue RCA. Includes two unit tests covering the gateway context and the standalone fallback (adapters=None). Only gap: CI status is NONE, no run on record.
• fix(plugins): use asyncio.wait_for instead of ClientTimeout in Matrix standalone send #61502 (+15/-7) — partial: replaces aiohttp.ClientTimeout with asyncio.wait_for in plugins/platforms/matrix/adapter.py::_standalone_send, removing the exact raise behind "Matrix send failed: Timeout context manager..." so the unencrypted raw-HTTP fallback works. The root cause from the RCA (manual runs delivering with adapters=None/loop=None off the gateway loop) remains unfixed: the live-adapter path (adapter.py:1661) still fails, and E2EE rooms are still downgraded to unencrypted HTTP, which the issue explicitly flags as something to avoid.

Suggested consolidation: merge #63586 — it fixes the cause (delivery of manual runs on the gateway loop) and preserves E2EE delivery via the live adapter, with a minimally invasive diff (one call site plus weakref resolution) and tests for both contexts; it needs a CI run first, as none exists yet (status NONE). #61502 should not be counted as a fix for #61495: it only repairs the unencrypted standalone fallback and cements the E2EE downgrade, though it could be pursued separately as a robustness patch for genuine standalone contexts (gateway not in-process). After #63586 merges, this issue should be closable; still open is the loop-awareness of send_message_tool._send_via_adapter suggested in the issue, which neither PR addresses.

Cross-PR triage: each diff was read against this issue; verdicts reflect diff content, not PR titles. Part of an automated triage batch.

[AiwendilInTheWoods]

Still reproduces on v2026.7.20 (gateway run, single profile, Matrix/mautrix adapter), on a manually-triggered cron job:

ERROR hermes_plugins.matrix_platform.adapter: Matrix: failed to send to <room> after retry:
  Timeout context manager should be used inside a task
ERROR cron.scheduler: Job '<id>': delivery error: Matrix send failed:
  Timeout context manager should be used inside a task

Worth adding: the job itself succeeds. It completed its tool calls and wrote its output file to disk; only delivery fails, so the failure is silent from the user's side unless you check the filesystem. For us this was previously masked by #65773 — jobs 401'd before reaching delivery — and surfaced only once that was guarded locally.