fix(bot): multi-project signal freeze — cache-only _get_channel + per-tick scanner cap
Root cause: When 3+ projects generated pending simultaneously, Bot's pending_approval_scanner made 20-40 Discord API calls in one tick (sequential await), triggering Discord 429 rate limits which blocked the entire scanner for 10-30s, freezing ALL signal delivery. Two fixes: 1. _get_channel(): Replace guild.fetch_channels() (API call) with discord.utils.get(guild.channels) (in-memory cache). Eliminates redundant API calls + Lock contention when multiple projects arrive. 2. pending_approval_scanner: Per-tick caps (5 new + 5 status) prevent one tick from monopolizing Discord API quota. Excess items are naturally processed in subsequent 3-second ticks.
This commit is contained in:
@@ -514,6 +514,12 @@
|
||||
- **해결**: (1) writeChatSnapshot을 루프 바깥으로 이동(resolvedCount > 0일 때 1회), (2) `pd.conversation_id === activeSessionId` 조건 추가, (3) primaryCommand에서 'Deny'/'Allow' 텍스트 제외
|
||||
- **주의**: Bridge 파일 루프에서 외부 시스템(Discord)에 메시지를 보낼 때는 반드시 루프 바깥에서 집계 후 1회 발송
|
||||
|
||||
### [2026-03-16] 멀티 프로젝트 동시 신호 정지 — Scanner O(N) Discord API + fetch_channels 병목
|
||||
- **증상**: 여러 프로젝트(3+)가 동시에 pending을 생성하면 모든 프로젝트의 신호 전달이 정지, AI 멈춤
|
||||
- **원인**: 2가지 복합: (1) `pending_approval_scanner`가 1 tick에 모든 pending(15건+)을 순차 처리 → 건당 `_get_channel()` + `channel.send/edit/fetch_message` Discord API 호출 → 20~40 API 호출이 Discord 429 rate limit 유발 → discord.py 내부 대기 → scanner tick 수십 초 블로킹 → 모든 프로젝트 신호 지연. (2) `_get_channel()`이 캐시 미스 시 `guild.fetch_channels()` (Discord API)를 asyncio Lock 내에서 호출 → Lock 대기 + API 호출 순차 발생
|
||||
- **해결**: (1) `_get_channel()`을 `discord.utils.get(guild.channels)` 캐시 기반으로 변경 — API 호출 제거, (2) scanner에 per-tick cap 추가 (Phase 1: 5건, Phase 2: 5건) — 나머지는 다음 tick으로 이월
|
||||
- **주의**: `guild.channels`는 discord.py 내부 캐시(Gateway 이벤트로 자동 갱신). 채널 삭제/생성은 캐시에 즉시 반영됨. per-tick cap은 최대 3초 지연을 유발하지만 전체 정지보다 훨씬 나음
|
||||
|
||||
### [2026-03-15] 이전 분석 오판(False Positive) — 교훈
|
||||
- **증상**: 시스템 감사 시 P0/P1으로 보고한 문제들이 실제로는 코드 방어 로직(멱등성, try-catch, 의도된 exact-match)으로 이미 방어되고 있었음
|
||||
- **원인**: 로컬 코드 스니펫만 보고 판단. 전체 데이터 생명주기를 끝까지 추적하지 않아 방어 로직을 놓침
|
||||
|
||||
Reference in New Issue
Block a user