fix(gateway): prevent Discord disconnects from blocking event loop

[itenev]

Replace synchronous requests.get() in models_dev with async variants using aiohttp and asyncio.to_thread() to offload blocking I/O, preventing event loop freezes that cause missed Discord heartbeats and ClientConnectionResetError disconnects.

Files changed:

• agent/models_dev.py: add fetch_models_dev_async(), lookup_models_dev_context_async()
• agent/model_metadata.py: add get_model_context_length_async() using asyncio.to_thread()
• gateway/run.py: switch 3 call sites to async variants

What does this PR do?

This PR fixes the frequent Discord gateway disconnects (ClientConnectionResetError: Cannot write to closing transport) caused by the event loop being blocked by synchronous HTTP requests.

Specifically, agent/models_dev.py uses requests.get() to fetch model metadata. Because this runs inside the single-threaded asyncio event loop, the call blocks all tasks—including Discord heartbeats—for up to 15 seconds. When the heartbeat is delayed, Discord closes the connection, leading to repeated disconnects and reconnections.

This PR introduces async variants using aiohttp (for the network fetch) and asyncio.to_thread() (for the synchronous resolution chain) to ensure the event loop remains responsive while resolving model context lengths.

Related Issue

N/A

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• agent/models_dev.py: Added fetch_models_dev_async() using aiohttp and lookup_models_dev_context_async().
• agent/model_metadata.py: Added get_model_context_length_async() which offloads the sync resolution chain to a thread pool via asyncio.to_thread().
• gateway/run.py: Updated 3 call sites in the message handling path to use the new async variants (await get_model_context_length_async(...)).

How to Test

1. Run the gateway with Discord enabled.
2. Trigger a message processing flow that requires model metadata resolution (e.g., context compression or session info).
3. Verify that agent.log no longer shows heartbeat blocked for more than 10 seconds or ClientConnectionResetError.
4. Run the relevant tests: pytest tests/agent/test_models_dev.py tests/agent/test_model_metadata.py -v`

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(gateway): prevent Discord disconnects from blocking event loop)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run 'pytest tests/agent/test_models_dev.py tests/agent/test_model_metadata.py' and all tests pass
• [] I've added tests for my changes (existing tests cover the resolution logic; async variants share the same underlying logic)
• I've tested on my platform:Ubuntu 24.04,

Documentation & Housekeeping

• N/A (No documentation changes required)
• N/A (No config keys changed)
• N/A (Architecture unchanged, just asyncification of blocking calls)
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — aiohttp and asyncio.to_thread are standard cross-platform.
• N/A (No tool behavior changed)

[teknium1]

Merged via PR #56212 (rebase-merge, your commit's authorship preserved in git log). #56212

We kept the core fix — get_model_context_length_async() offloading the sync resolution chain via asyncio.to_thread(), plus the two async gateway call-site swaps — which is what actually stops the blocking requests.get from starving Discord heartbeats. Verified E2E: event-loop gap dropped from ~490ms to 52ms during a cold-cache fetch.

We dropped the fetch_models_dev_async/lookup_models_dev_context_async aiohttp variants: they had no callers and the to_thread wrapper already runs the existing sync path off-loop, so they were redundant (and had drifted from the sync cache logic). Thanks for the fix!