[Bug] CoPaw process pegged at 100% CPU at idle (busy-polling epoll loop) #2218
Description
CoPaw Version
0.2.0
Description
The CoPaw main Python process is pegged at ~100% CPU from the moment it starts, even with no active conversations or tasks. The CPU usage is sustained and does not drop at idle.
Related PR(s): N/A
Security considerations: None
Component(s) Affected
- Core / Backend (app, agents, config, providers, utils, local_models)
- Console (frontend web UI)
- Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- Skills
- CLI
- Documentation (website)
- Tests
- CI/CD
- Scripts / Deploy
Environment
- CoPaw version: 0.2.0
- OS: Debian GNU/Linux 12 (Bookworm), running in a Proxmox LXC container
- Install method: pip (one-line install)
- Python version: 3.12.13
Steps to Reproduce
- Start CoPaw with
copaw app --host 0.0.0.0 - Leave it idle — no active conversations or tasks
- Run
topand observe the CoPaw process
Actual vs Expected
- Actual: CoPaw process consumes ~100% CPU continuously from startup, even at idle. After 5 minutes of uptime, it had already accumulated ~5 minutes of CPU time (nearly 1:1 ratio with wall clock time).
- Expected: At idle, CoPaw should consume near 0% CPU, blocking on I/O events until a new message or task arrives.
Logs / Screenshots
Profiling with strace -p <pid> -c -f over 5 seconds:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
83.86 x.xxxxxx xx 162 clock_nanosleep
14.71 x.xxxxxx 0 192857 epoll_pwait
...
------ ----------- ----------- --------- --------- ----------------
epoll_pwait is being called ~38,500 times per second, strongly suggesting a busy-polling loop in the async event loop. A coroutine is likely calling asyncio.sleep(0) or using a near-zero timeout in a while True loop, causing the event loop to spin continuously instead of blocking properly.
Process had 31 active threads at time of profiling.
Additional Notes
- Confirmed reproducible across multiple container restarts
- Kernel:
6.8.12-20-pve(Proxmox VE kernel) - The issue persists at idle with zero active conversations, ruling out load from LLM calls or tool execution