fix(gateway): scale-to-zero never armed — arm-gate counted disabled placeholder platforms

[benbarclay]

Infographic

Summary

The scale-to-zero idle watcher never armed on a correctly-opted-in, relay-only instance, so the gateway never ran its idle decision, never called go_dormant(), and never sent going_idle to the connector. Fly's autostop still suspended the machine on traffic-idle, but because the connector never flipped the instance to buffered-only, an inbound DM took the live delivery path, found no live session for the suspended machine, and was dropped fail-closed with no wake poke. The machine slept and never woke.

Root cause

_scale_to_zero_should_arm() passed list(self.config.platforms.keys()) to messaging_is_relay_only_or_absent(). But config.platforms is pre-seeded with a disabled placeholder PlatformConfig for every known platform (telegram, discord, slack, matrix, …), so the key set is always the full ~20-entry catalog regardless of what the instance actually runs. The relay-only check discarded "relay", saw the disabled placeholders as live direct-socket platforms, and returned False — so should_arm() was False and the watcher task was never created.

Verified live on a staging instance (paradoxical-schooner-7460):

• config.platforms keys = [telegram, discord, slack, mattermost, matrix, relay] — only relay is enabled=True, the rest are disabled placeholders.
• should_arm() evaluated to False; no scale-to-zero: armed line in the gateway log between relay adapter registered and Press Ctrl+C to stop.
• The full dead chain: no watcher → no go_dormant() → no going_idle → connector flip set (gg:relay:buffered-only) empty → DM live-path drop → no wake poke.

Fix

Filter config.platforms to enabled entries before the relay-only check, mirroring the adapter-connect loop which already gates on if not platform_config.enabled: continue. This arms off the same notion of "active platform" the rest of start() already uses — no parallel concept introduced.

Also adds a one-line not-armed diagnostic: when an instance is opted in (the HERMES_SCALE_TO_ZERO stamp is set) but the watcher still doesn't arm, it now logs why (relay_only_or_absent, the enabled platforms, wake_url present/missing). A non-opted instance stays silent. Previously the arm path logged only on success, so a failed arm was invisible — this bug needed an on-box predicate eval to diagnose.

Tests

The existing pure-helper tests (test_scale_to_zero.py) passed bare platform names to messaging_is_relay_only_or_absent, so they never exercised the call site that feeds the placeholder-laden config — which is exactly why the bug shipped green. New behaviour-contract tests in test_scale_to_zero_watcher.py drive the real _scale_to_zero_should_arm against a realistic config.platforms:

• test_arm_true_for_relay_only_with_disabled_placeholders — relay enabled + all others disabled placeholders must arm (the F25 regression; RED without this fix).
• test_arm_when_no_platform_enabled_at_all — Chronos-only / no-messaging agent arms (also RED without the fix).
• test_no_arm_when_a_direct_platform_is_actually_enabled — a genuinely-enabled Discord does disarm (the filter must not over-broaden).
• test_no_arm_when_not_opted_in / test_no_arm_without_wake_url — the other two arm preconditions still gate correctly.

RED-proven: with the call-site fix reverted, the two arm-positive tests fail; with it restored, all 51 scale-to-zero tests pass.

Wake mechanism — verified healthy independently

The wakeUrl + Fly autostart path itself is fine: a direct wakeUrl GET resumed the suspended staging instance suspended → started in 1.15s with a clean resume event signature (proxy start/starting → flyd start/started, not a cold create). That 1.15s is also the Phase-3 wake-latency measurement. The bug was purely that the gateway never set up the conditions for the connector to issue that poke.

Scope

gateway/ only — the scale-to-zero arm gate. Behavior-preserving for every non-opted instance (they never armed before and still don't; the filter only changes the relay-only opted-in case, which is the broken one).

[github-actions]

🔎 Lint report: fix/scale-to-zero-arm-enabled-filter vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 11362 on HEAD, 11364 on base (✅ -2)

🆕 New issues (1):

Rule	Count
invalid-assignment	1

First entries

tests/run_agent/test_credits_notices_toggle.py:76: [invalid-assignment] invalid-assignment: Object of type `None` is not assignable to attribute `_credits_session_start_micros` of type `int`

✅ Fixed issues (2):

Rule	Count
unresolved-attribute	2

First entries

tests/run_agent/test_credits_notices_toggle.py:76: [unresolved-attribute] unresolved-attribute: Unresolved attribute `_credits_session_start_micros` on type `AIAgent`
run_agent.py:2989: [unresolved-attribute] unresolved-attribute: Object of type `Self@get_credits_spent_micros` has no attribute `_credits_session_start_micros`

Unchanged: 5992 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.

[tonydwb]

Code Review Summary

Verdict: Approved

Precise fix for the F25 regression where scale-to-zero never armed on relay-only instances. The root cause was clear: config.platforms.keys() returns the full ~20-entry catalog of all KNOWN platforms (including disabled placeholders), which made messaging_is_relay_only_or_absent see disabled discord/telegram/etc. as live direct-socket platforms and refuse to arm.

Looks Good

• Fix is minimal and surgical: filters to enabled platforms only (getattr(pc, "enabled", False)), mirroring the connect loop
• New _log_scale_to_zero_not_armed_reason() diagnostic method is well-scoped — only fires for opted-in instances, stays silent otherwise
• Comprehensive test suite (5 tests covering: relay-only with placeholders, genuinely-enabled direct platform, no platforms enabled, not opted in, no wake URL)
• _arm_runner test helper is well-designed to mirror real load_gateway_config() shape
• Exception handling is appropriate (noexcept-style with noqa: BLE001)

---

Reviewed by Hermes Agent