Repository navigation
Console Log Loading Issue in Chrome Desktop: Continuous Timeout Loop for /api/log, While Mobile Works Fine #2791
Description
Client or integration
Codex CLI
Area
Web
Summary
When viewing logs in Google Chrome on a desktop computer, the request to /api/log fails to load properly. It times out after 30 seconds, and then automatically triggers a new request, which also times out — resulting in an endless loop of repeated timeouts. However, the same operation works perfectly fine in Google Chrome on a mobile device, where the logs appear quickly without any delay.
Reproduction
ocx start on centos 7.6
Version
2.33.0
Operating system
An unofficial Node.js 22 build that works with glibc 2.17 on CentOS 7.6
Provider and model
No response
Logs or error output
Screenshots and supporting files
No response
Redacted configuration
Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
lidge-jun commentedon Aug 28, 2026
리뷰 · 우선순위 54 / 80
이 이슈는 데스크톱 Chrome에서 로그 화면이
/api/log를 30초 타임아웃으로 반복 호출하고, 모바일 Chrome에서는 바로 뜬다는 보고입니다. 작성자는 spinachomes입니다. 환경은 CentOS 7.6, glibc 2.17용 비공식 Node 22, OpenCodex 2.33.0입니다. 라벨은 bug, cli입니다. 화면은 대시보드 로그라 cli보다 gui/proxy가 맞습니다. 지금devHEAD는50e955604이고 package.json은 2.35.0입니다. 본문에 로그와 설정이 비어 있습니다. 구현 풀은 없습니다.실제 경로는 단수
/api/log가 아닙니다.gui/src/pages/Logs.tsx420줄은GET ${apiBase}/api/logs?limit=2000입니다. 서버는src/server/management/logs-usage-routes.ts136줄에서 그 경로를 받습니다. 링 버퍼 상한은src/server/request-log.tsMAX_LOG_SIZE = 2000(188줄)이라, 프론트가 링 전체를 그대로 달라고 합니다. 폴은 2초입니다. 한 번의 기한은gui/src/client-resource.tsDEFAULT_REQUEST_DEADLINE_MS = 30_000(66줄)입니다. 30초가 지나면 abort하고, autoRefresh가 켜져 있으면 다시 같은 요청을 보냅니다. 본문의 무한 타임아웃 루프와 숫자가 같습니다.데스크톱만 실패하는 이유는 코드에 데스크톱 분기가 없어서입니다. 더 그럴듯한 후보는 페이로드 크기와 네트워크 경로입니다. 2000개 로그 DTO는 시도, 사용량, 에러 문구가 붙으면 수 메가바이트가 됩니다. 데스크톱 Chrome이 원격 CentOS 호스트에 직접 붙고, 모바일은 다른 망이거나 로그 양이 적은 세션일 수 있습니다. 같은 작성자의 #2792는 Nginx 없이
index.jsContent-Length가 어긋나 흰 화면이 됩니다. 로그 API가 같은 직접 HTTP 경로에서 길게 끊길 수도 있습니다. 다만 로그 화면이 열린 뒤에는 번들은 이미 로드된 상태라, 둘을 한 버그로 닫으면 안 됩니다. types.ts/config.ts 분할과 무관하고, preview deploy도 필요 없습니다.라인 420 - gui/src/pages/Logs.tsx가 /api/logs?limit=2000을 2초마다 다시 받습니다. 본문의 /api/log 단수는 오타로 보면 됩니다.
라인 66 - gui/src/client-resource.ts 기본 기한이 30초입니다. 본문 숫자와 같습니다.
라인 136 - src/server/management/logs-usage-routes.ts는 필터 후 링 전체를 JSON으로 줍니다. 스트리밍이 없습니다.
라인 188 - src/server/request-log.ts MAX_LOG_SIZE가 2000입니다. 프론트 limit과 같습니다.
이슈 본문 - HAR, 응답 바이트, 데스크톱이 프록시에 어떻게 붙는지가 없습니다.
이슈 #2792 - 같은 호스트의 정적 파일 길이 오류입니다. 링크로 묶고 닫지 마세요.
메인테이너의 판단이 필요한 지점
너의 추천
이 이슈는 엽니다. 닫지 말 것. 작성자에게 데스크톱 요청 URL이 정말
/api/logs인지, 30초 동안 응답 헤더가 오기나 하는지, 페이로드 크기, Nginx 유무를 부탁하세요. 코드 후보는 2000개 통째 JSON과 30초 기한의 조합입니다. #2792와 중복 처리하지 마세요. 라벨은 그대로 둡니다. 내가 머지하지 않습니다.이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Aug 28, 2026
Fixed on
devby commit e546c16 (PR #2859).Measured first, and the server turned out not to be the problem:
/api/logsreturns 2,000 entries (1.29 MB) in 1.97–2.69 ms and does not hang. The loop was on the client — a failed request was retried immediately, on the next tick, with no backoff. One failure therefore became a continuous stream of requests, which is why it looked like a timeout loop.Network attempts now back off 4/8/16/32 seconds. Manual retry and recovery stay immediate, so the UI still feels responsive when you ask it to reload.
That also explains the desktop-versus-mobile difference you noticed: the loop needed an initial failure to start, so whichever surface happened to hit one first appeared broken while the other looked fine — rather than anything mobile-specific.
Verified with the RED case reproducing the next-tick retry, then GREEN at 9/9, plus GUI lint, build, and a rendered screenshot.
This PR targeted
dev, so GitHub did not auto-close the issue — closing manually.