fix(cron): multiplex delivery uses owning profile's bot token and adapter (#83182)

[dongjiang1989]

Summary

Closes: #83182

Under a multiplex gateway (multiple per-profile Telegram bots etc.), cron jobs owned by a secondary profile deliver to the wrong bot/chat. Telegram logs show Thread 9539 not found ... retrying without message_thread_id — the thread is dropped because the bot token used at delivery time does not own it.

The root cause has two parts:

1. cron/scheduler.py::run_one_job installs the job-owning profile's secret scope, then resets it in the finally block between run_job and _deliver_result. By the time delivery runs, current_secret_scope() is None — load_gateway_config() → _getenv() falls back to os.environ (empty in the multiplex unit) — TELEGRAM_BOT_TOKEN resolves to the wrong bot (or nothing).

2. The gateway starts the cron ticker with the shared runner.adapters dict (the default profile's live adapters). _deliver_result → resolve_delivery_transport(...) only ever consults that shared dict. It never reaches Gateway._profile_adapters[<job profile>], so even when the token happens to be right, cron delivery cannot reach the secondary profile's live adapter.

This is distinct from existing issues #51853 and #54675 — their fix (PR #59315, commit 0f154e7) covers only adapter startup, not cron delivery-time scope reset / shared-adapter usage.

What does this PR do?

Two fixes, both required to close the bug:

• Part 1 — Scope lifetime: Move reset_secret_scope from the inner finally (after run_job) to an outer finally (after delivery). The profile's secret scope now stays installed through both execution and delivery, so load_gateway_config() picks up the right TELEGRAM_BOT_TOKEN from the owning profile's .env.

• Part 2 — Per-profile adapters: gateway/run.py builds profile_adapters_by_home — a mapping from resolved profile home path to that profile's live adapter map (sourced from runner._profile_adapters for secondary profiles, runner.adapters for the default). This map is threaded through the cron chain: scheduler_provider.start → _start_multiplex → cron_tick → run_one_job → _deliver_result. run_one_job resolves the owning profile's adapter map via the current hermes home (already set by _start_multiplex's per-profile override), so delivery picks the right bot token.

When profile_adapters_by_home is not set (single-profile mode, direct CLI ticks, external providers), the code falls back to the shared adapters dict — fully backward compatible.

Related Issue

Fixes #83182

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor
• 🎯 New skill

Changes Made

cron/scheduler.py

• Part 1: Restructure the try/finally in run_one_job. The inner finally: reset_secret_scope(_scope_token) is replaced with an outer finally that wraps both run_job and the delivery block. Agent teardown stays in the inner finally (its existing contract, unchanged).
• Part 2: Add profile_adapters_by_home parameter to tick and run_one_job; add profile_adapters parameter to _deliver_result. run_one_job resolves the owning profile's adapters from the map keyed by the current hermes home path. _deliver_result prefers the profile-specific adapters over the shared dict when both are present.
• DeliveryRouter and resolve_delivery_transport call sites updated to use the resolved delivery_adapters.

cron/scheduler_provider.py

• InProcessCronScheduler.start and _start_multiplex accept and propagate profile_adapters_by_home down to cron_tick.

gateway/run.py

• At cron start, when multiplex_profiles is on, build profile_adapters_by_home from runner._profile_adapters (secondary profiles) plus runner.adapters (default profile), keyed by resolved hermes home path. Pass to the cron scheduler via cron_start_kwargs.

tests/cron/test_cron_multiplex_delivery_83182.py (new)

• TestSecretScopeThroughDelivery — verifies the scope-reset ordering (deliver → reset, not reset → deliver).
• TestProfileAdapterSelection — verifies profile-specific adapters are preferred over shared, with fallback.
• TestRunOneJobProfileAdaptersResolution — verifies run_one_job correctly looks up the right adapter map from profile_adapters_by_home.
• 6 new regression tests, all passing.

tests/cron/test_run_one_job.py / test_preflight_config.py

• Adapt fake_deliver signatures to accept the new profile_adapters=None kwarg. No behavioral changes.

How to Test

1. scripts/run_tests.sh tests/cron/test_cron_multiplex_delivery_83182.py — 6 tests pass.
2. scripts/run_tests.sh tests/cron/test_run_one_job.py tests/cron/test_preflight_config.py — 13 tests pass, no regression.
3. End-to-end under a multiplex gateway with two Telegram profiles: create a cron job owned by the secondary profile, wait for it to fire. Pre-fix: delivers via the default bot, logs Thread ... not found. Post-fix: delivers via the secondary profile's bot to the correct chat.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix
• I've run the test suite and the affected tests pass
• I've added tests for my changes
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (docstrings) — added inline comments explaining both fixes
• I've updated cli-config.yaml.example if I added/changed config keys — N/A (no config changes)
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture — N/A
• I've considered cross-platform impact — N/A (no platform-specific code)
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

[dongjiang1989]

cc @alt-glitch PTAL, thanks

[Enough1122]

AI code review — automated review for reference, author can ignore or act on any point.

fix(cron): multiplex delivery uses owning profile's bot token and adapter (#83182)

1. gateway/run.py — the new block iterates for _pname, _phome in profile_homes: assuming every element is a 2-tuple, but the log line a few lines above defensively handles string elements (p[0] if isinstance(p, tuple) else p). If profile_homes can contain plain strings, this unpacking raises ValueError; the surrounding try/except Exception swallows it, so per-profile adapters silently never get wired (multiplex cron keeps the old wrong-bot behavior with only a warning). Please confirm the element shape and, if strings are possible, normalize before unpacking.
2. gateway/run.py — the per-profile adapter maps are shallow-copied once at gateway startup (dict(_amap)). If a secondary profile's adapters are later replaced wholesale (reconnect/restart rebuilding the adapter dict), cron delivery keeps using the stale snapshot. Resolving the map lazily at delivery time (or refreshing it per tick) would better match the "live adapter map" intent in the comments.
3. Minor: _deliver_result's profile_adapters docstring calls it the "live adapter map", but the value is a startup snapshot; a note saying so would prevent future maintainers from assuming object identity with runner.adapters.

[dongjiang1989]

Thanks for the review. Analyzed all 3 points:

1. Tuple unpacking — not an issue. profiles_to_serve() has return type List[Tuple[str, Path]] and always yields 2-tuples. The defensive isinstance(p, tuple) check in the log line is legacy paranoia, not a real code path. No normalization needed.

2. Stale adapter snapshot — not an issue in practice. Adapter instances in _profile_adapters[profile] are never replaced after registration — see gateway/run.py:13866: if platform not in profile_map: profile_map[platform] = adapter. Reconnects mutate the existing adapter in place; they do not swap the object. The shallow dict(_amap) copy shares the same adapter instances with the gateway, so cron sees the same live state.

3. Docstring — fair nit but the behavior is correct. "Live adapter map" refers to the fact that the dict holds live adapter references (shared with gateway), not that the dict itself is refreshed. Adding "(shared references to live adapter instances)" would clarify without changing semantics; will do if desired.

[teknium1]

Thanks @dongjiang1989 — you proposed hoisting the secret-scope reset out of the run-block finally 12 days before the equivalent fix landed, and your follow-up on the review points (tuple shape, adapter identity stability) was correct. Reviewed against current origin/main: both halves of this PR are now in via #99375 —

• 07f6518b6d6 (@ghosty93) — function-level finally reset in run_one_job, cron/scheduler.py:7823-7829.
• 51e377d550f + a07370abd05 (@MuhammadUsamaMX, fix(cron): deliver each profile's cron via its own adapter in multiplex #73363, which predates this PR) — profile_adapters threaded into _start_multiplex, per-profile map per tick, cron/scheduler_provider.py:736-747.

Closing as redundant with credit; #83182 is closed as fixed with your name on it.