브라우저를 기동해 사이트로 이동하고 스크린샷을 생성한 뒤 텔레그램으로 전송하는 경로를 정리하고, 최근 발생한 무응답/지연 알림 문제를 함께 복구한 작업 기록이다.

<aside> 🛠️ 민감정보 보호 원칙: 맥미니의 개인정보, API 키, 토큰 값은 문서에 포함하지 않았다. 예시 파일은 로컬 생성 산출물 경로만 기록했다.

</aside>

목표

• 텔레그램 요청으로 브라우저를 열고 대상 사이트로 이동한 뒤 스크린샷을 생성한다.
• 생성된 스크린샷을 텔레그램 채팅으로 안정적으로 전송한다.
• 이번 요청에서 새로 연 브라우저 탭/창만 닫고, 사용자가 기존에 열어둔 창은 유지한다.
• 작업 단위를 job_id로 추적해 진행 알림, 완료 전송, 복구 전송을 서로 충돌 없이 처리한다.

주요 수정 사항

• telegram_router_bridge.py에 chat_id별 백그라운드 큐와 워커를 두어 긴 작업이 getUpdates 루프를 막지 않도록 변경했다.
• OpenClaw agent 응답에서 텍스트뿐 아니라 MEDIA:/... 경로와 세션 로그 details.path를 회수해 사진 전송으로 연결하도록 보강했다.
• 브라우저 계열 요청에는 작업 종료 후 새로 연 탭/창만 닫으라는 지시를 자동으로 덧붙이도록 했다.
• send_reply, worker, recovery_loop에 job_id 기반 상태 추적을 넣어 queued/running/sent/recovered 상태를 기록하도록 했다.
• watchdog가 세션 로그에서 assistant 최종 응답과 스크린샷 경로를 복구해 텔레그램으로 재전송할 수 있게 했다.
• 진행 알림은 sent_at 존재 여부를 확인한 뒤 전송하도록 바꿔, 완료 후 늦게 도착하는 진행 메시지를 차단했다.

프로세스 흐름

flowchart TD
    A[Telegram message] --> B{Background job}
    B -- No --> C[Immediate handle_update reply]
    B -- Yes --> D[Enqueue job_id by chat_id]
    D --> E[Worker starts job]
    E --> F[OpenClaw agent runs browser task]
    F --> G{Reply sent}
    G -- Yes --> H[Mark sent_at]
    G -- No --> I[Watchdog scans session log]
    I --> J[Recover text and media paths]
    J --> H
    H --> K[Progress alerts stop after sent_at]

문제와 원인

• 같은 봇 토큰으로 중복 polling이 일어나면 Telegram getUpdates 409 충돌이 발생해 응답이 불안정해졌다.
• 브라우저 스크린샷은 생성되었지만 브리지가 MEDIA 경로를 놓치면 텔레그램에는 텍스트만 오거나 아무 응답이 없었다.
• 백그라운드 큐 도입 초기에는 enqueue 단계에서 job_id 인자 중복 전달 버그가 있어 아예 작업이 시작되지 않는 경우가 있었다.