SRT booking: dynamic results not found / automation detection during select

[kjun0481-boop]

Summary:
I tried to automate SRT reservation using the srt-booking skill following the README (login via KSKILL_SRT_ID/KSKILL_SRT_PASSWORD, SRTrain search, and browser automation like Playwright). Observed behaviour:

• SRTrain search returns '접속자가 많아 대기열에 들어갑니다.' or no results (FOUND 0) intermittently even when the train exists.
• Playwright headful login + human-like typing works for login, but search results appear rendered dynamically; script cannot reliably find the train row (e.g. 618) or its reservation button.
• Attempts to locate 618 via text-search and DOM scanning fail because the result UI seems to be rendered by separate scripts/iframes or updated after initial load, and the reservation button isn't present in the same DOM subtree as the train text.
• When trying to automate human-like interactions, the site shows warnings or blocks that look like bot-detection (e.g. forced 'queue' messages rather than real results).

Environment:

• macOS (arm64), Python 3.11, SRTrain 2.6.7, Playwright 1.34.0, running on a local dev machine.
• K-skill repo clone at commit: main (local workspace).

What I tried:

• SRTrain search with multiple time windows (found other trains but not the desired train id).
• Playwright: headful browser, human-like typing, mouse movement, JS DOM evaluation to find buttons by scanning rows, fallback heuristics.
• Keychain + secrets.env credentials usage, respecting the skill's credential resolution order.

Request:

• Can the srt-booking skill docs or helper scripts include selectors and robust logic for the current SRT result layout (the code that determines where the reservation button lives relative to the train row)?
• Any known anti-bot behaviors to expect and mitigation guidelines (delays, fingerprinting, cookies reuse, user gestures) would be helpful to include in the README.

Additional info I can provide: console logs, Playwright traces, session cookies, or an anonymized recording of DOM when the search results render.

Tagging: this is an automation/debugging issue for srt-booking; please advise the best next steps.

[kjun0481-boop]

I prepared anonymized evidence (DOM snapshot and network log) that may help diagnose the srt-booking issues. Files: srt_dom_anonymized.html, srt_network_anonymized.json.\n\nI can attach them here if you want (they contain masked tokens and removed sensitive fields). Please let me know if you'd like me to upload the anonymized files to this issue.

[vkehfdl1]

• AI-understood issue summary
  This report combines two separate failure modes: (1) upstream SRT/SRTrain intermittently returns queue or empty search results even when a known train exists, and (2) browser automation against the live SRT select page cannot reliably map a train row to its reservation button because the results appear to be rendered dynamically and are sometimes guarded by anti-automation behavior.

• Why this issue is needed
  Current repo guidance (docs/features/srt-booking.md and srt-booking/SKILL.md) documents the SRTrain-first happy path, but it does not explain queue responses, intermittent FOUND 0, or the practical limits of Playwright-style DOM automation on the current SRT site. That makes it hard for users to tell whether they hit an upstream transient, an unsupported automation path, or a real doc gap.

• Why this issue may not be needed
  If we hold the scope strictly, the skill promises SRTrain-based search/reserve/cancel flows and explicitly does not promise stable website selectors or full browser automation. In that interpretation, the right fix may be documentation-only: clarify that live-site DOM automation is unsupported/brittle, instead of adding selectors that will likely rot quickly or drift into bot-evasion guidance.

• Expected Outcome

  • Clarify the supported path: SRTrain-based lookup/reservation remains the primary workflow.
  • Add a troubleshooting section for queue responses, intermittent empty results, and target-train mismatch.
  • Document that web UI automation/selectors are best-effort for debugging only, not a guaranteed booking surface.
  • Add an evidence checklist for future reports (DOM snapshot, frame tree, network trace, exact query parameters, timestamp).

• Concise implementation plan

  1. Update docs/features/srt-booking.md and srt-booking/SKILL.md with Known limitations and Troubleshooting sections.
  2. Document bounded retry guidance for upstream queue/empty-result behavior, and explain that these can be transient upstream conditions rather than repo-side bugs.
  3. Explicitly state that we should not ship or promise stable Playwright selectors for the live SRT booking UI unless we can prove a durable, maintainable anchor.
  4. If we add anything code-adjacent, keep it diagnostic-only (e.g. DOM/frame dump instructions or trace-capture guidance), not anti-bot bypass logic.
  5. Use the reporter's anonymized DOM/network artifacts to confirm whether a stable selector strategy exists at all before opening a separate implementation bug.

My recommendation: keep this open as a docs/troubleshooting issue first. If the anonymized evidence shows that our documented SRTrain path is regressing independently of browser automation, split that into a follow-up bug with a narrower scope.

[kjun0481-boop]

추가 설명: 지금까지 여러 차례 테스트하면서 가장 문제되는 점은 SRTrain/브라우저에서 '접속자가 많아 대기열에 들어갑니다.' 메시지가 반복해서 나오고, 이는 단순한 트래픽 혼잡으로 보기 어렵다는 점입니다.\n\n관찰된 증상 요약:\n- SRTrain으로 직접 조회 시점에 '대기열' 메시지 또는 빈 결과가 반환됨(특정 편을 반복 검색해도 동일).\n- Playwright headful(사람처럼 입력)으로 로그인·검색을 해도 검색 결과 영역에 기대한 열차 행(예: 618)이 렌더되지 않거나 예약 버튼이 별도 DOM에 있어 자동화로 찾기 어려움.\n- 사람이 직접 브라우저로 로그인한 세션에서는 결과가 보일 때가 있지만, 자동화/스크립트로 접근하면 일관되게 대기열/차단 상태가 발생했습니다.\n\n추정: 사이트 쪽에서 자동화(봇) 탐지 로직을 작동시켜 특정 세션/요청을 대기열 메시지로 분기시키는 것 같습니다(단순 과부하 응답과 다르게 보임).\n\n요청:\n1) maintainer님들께서 SRT 결과 페이지의 현재 렌더 방식(예: 프레임/동적 로딩/비동기 API 엔드포인트)과, 자동화가 차단되는 알려진 패턴(특정 헤더/쿠키/지연 요구 등)이 있는지 공유해주실 수 있을까요?\n2) 이 리포지토리의 srt-booking이 안정적으로 동작하려면 어떤 우회(정식 API 사용 권장, storageState 세션 재사용, 특정 wait 조건 등)를 권장하시는지 알려주세요.\n\n참고: 익명화된 DOM 스냅샷과 네트워크 로그(srt_dom_anonymized.html, srt_network_anonymized.json)를 준비해 두었고, 필요하시면 이 이슈에 첨부·공유 가능합니다.\n\n감사합니다. -- 자동화/차단 현상 재현/분석을 시도한 사용자 드림

[kjun0481-boop]

Maintainer guidance received — I'm following your instructions and will run through the steps you suggested.\n\nActions I will perform now (per your guidance):\n1) Recreate an anonymized DOM snapshot & network log and upload as a gist (done): https://gist.github.com/kjun0481-boop/5094c10535439905c295678a2f236283\n2) Attempt to reproduce using the SRTrain library across multiple time windows and collect any queue/empty responses (I have scripts ready and will run them on demand).\n3) Prepare a storageState (Playwright) session capture using a headful login so we can test session-reuse behavior (will request manual login once before capture).\n4) Provide the maintainer the anonymized artifacts and any trace logs if further debugging is needed.\n\nPlease advise if you want me to proceed with step 2 (SRTrain broad re-check) and/or step 3 (storageState capture) now. I'll proceed with whichever you prefer.

[kjun0481-boop]

I ran a broad SRT search sweep across multiple start times for 2026-04-17 and saved anonymized results (found counts / errors). Gist with results: https://gist.github.com/kjun0481-boop/d747e96deb4b861012db032e7acddc17\n\nSummary:\n- 00:00 found 6 trains\n- 06:00 found 4 trains\n- 09:00 found 2 trains\n- 12:00 found 0 trains\n- 15:00 found 0 trains\n- 18:00 found 0 trains\n- 19:00 found 0 trains\n- 20:00 found 0 trains\n- 23:00 ERROR: 조회 결과가 없습니다. [WRG000000]\n\nNotably, multiple attempts returned a queue message ('접속자가 많아 대기열에 들어갑니다.') and intermittent empty results — this appears consistent with either upstream queueing or targeted session-level blocking. Attaching the anonymized result set in case it helps.\n

[vkehfdl1]

추가 재현 정보 감사합니다. 지금 올라온 증상만 보면, 이건 결과 페이지 셀렉터 한두 개를 보강해서 해결될 문제라기보다, 검색 단계 자체에서 세션/요청이 대기열·빈결과 경로로 분기되는지 먼저 확인해야 하는 상황으로 보입니다.

현재까지의 정리:

• 사람이 직접 연 세션에서는 결과가 보일 때가 있는데, SRTrain/자동화 세션에서는 반복적으로 접속자가 많아 대기열에 들어갑니다. 또는 빈 결과가 나온다는 점은, 단순 DOM 탐색 실패만으로 설명되지는 않습니다.
• 즉 618 행을 못 찾는다는 현상도 결과 DOM 렌더 이전에 upstream 쪽에서 다른 응답 경로로 보내고 있을 가능성이 큽니다.
• 그래서 이 저장소 기준으로는, 지금 단계에서 “안정적인 Playwright 셀렉터/헤더/쿠키 우회법”을 README에 약속하는 건 적절하지 않습니다. 그런 내용은 금방 깨지기도 하고, bot-evasion 가이드가 되기 쉽습니다.

질문 주신 2가지에 대한 현재 답변:

1. 현재 렌더 방식 / 알려진 차단 패턴
   이 리포지토리 안에는 SRT 결과 페이지의 최신 프레임 구조나 비동기 엔드포인트를 보장하는 코드가 아직 없습니다. 그래서 maintainer 관점에서도 지금은 확정적으로 “이 프레임/이 API/이 헤더가 원인”이라고 말할 근거가 부족합니다. 우선 올려주신 익명화 DOM/네트워크 로그를 기준으로, 실제로 결과가 iframe/XHR 기반인지, 아니면 서버 응답 단계에서 이미 queue/empty 분기가 나는지부터 확인하는 게 맞습니다.

2. 이 저장소에서 권장할 안정 경로
   현재 기준 권장 경로는 여전히 SRTrain 우선입니다. 다만 반복적인 queue/empty가 보이면 이를 “지원되는 정상 결과 없음”이 아니라 upstream transient / session gating 가능성으로 문서에 명시할 필요가 있습니다. storageState 재사용이나 특정 wait 조건은 진단용으로는 도움이 될 수 있어도, 저장소 차원에서 “안정 우회책”으로 약속하진 않겠습니다. 특히 브라우저 자동화 셀렉터는 공식 지원 surface로 두기 어렵습니다.

그래서 다음 액션은 이렇게 가져가면 좋겠습니다:

• 올려주신 DOM snapshot / network log / broad search sweep 결과를 바탕으로, 문서 보강 이슈로는 바로 진행합니다.
  • docs/features/srt-booking.md
  • srt-booking/SKILL.md
    여기에 Known limitations / Troubleshooting / Evidence to attach when reporting 섹션을 추가하는 방향이 적절합니다.
• 그 다음, 첨부 로그를 보고도 SRTrain 자체가 특정 시간대/조건에서 비정상적으로 queue 또는 empty를 반복하는 패턴이 확인되면, 그건 별도 하위 이슈로 분리해서 재현 스크립트 기준으로 추적하는 게 좋겠습니다.

가능하시면 이미 준비하신 익명화 아티팩트(gist 포함)를 이 이슈에 그대로 링크/첨부해 주세요. 그러면 “DOM 셀렉터 문제”와 “검색 단계 차단/분기 문제”를 분리해서 판단하는 데 큰 도움이 됩니다.

[vkehfdl1]

정리해 주신 follow-up 방향에 동의합니다. 현재 이 이슈는 우선 docs/troubleshooting 범위로 유지하는 게 맞고, 핵심 판단도 다음 두 줄로 요약될 것 같습니다.

• srt-booking의 공식 지원 경로는 계속 SRTrain-first 입니다.
• 라이브 SRT 웹 UI에 대해 안정적인 Playwright 셀렉터나 자동화 우회 절차를 저장소 차원에서 보장하지는 않습니다.

특히 이번 후속 정리에서 중요한 점은, 문제를 아래 두 축으로 분리해 준 부분입니다.

1. 검색 단계 문제: queue / FOUND 0 / WRG000000 같은 응답이 반복되는지
2. 렌더 단계 문제: 결과가 실제로 렌더된 뒤에도 train row ↔ reserve button 매핑이 깨지는지

이 분리가 있어야, 단순 셀렉터 개선 요청과 upstream/session gating 의심 사례를 섞지 않고 판단할 수 있습니다.

그래서 이 이슈 기준의 다음 처리 방향은 이렇게 가져가겠습니다.

• docs/features/srt-booking.md 와 srt-booking/SKILL.md에 아래 내용을 보강하는 방향이 타당합니다.
  • Known limitations
  • Troubleshooting
  • Evidence to attach when reporting
• 문서에는 특히 아래를 명시하는 게 좋겠습니다.
  • queue/empty-result는 항상 “열차 없음”을 뜻하는 것이 아니라 upstream transient 또는 session-level gating 가능성이 있음
  • Playwright/브라우저 자동화는 진단 보조 수단일 수는 있어도, 공식 지원 booking surface는 아님
  • anti-bot bypass처럼 해석될 수 있는 헤더/쿠키/지문 우회법은 저장소 문서에 싣지 않음

반대로, 만약 이미 공유된 gist / anonymized artifacts를 검토한 뒤에도 SRTrain 경로 자체가 특정 조건에서 구조적으로 깨진다는 근거가 더 쌓이면, 그때는 이 이슈에서 분리해서 재현 스크립트 중심의 하위 버그로 다루는 편이 좋겠습니다.

즉, 이번 follow-up은 이 이슈의 방향을 더 명확하게 해 준 것으로 보고, 당장은 “웹 자동화 셀렉터 추가”보다 “지원 범위/제한/증거 수집 절차 문서화”가 우선이라는 쪽으로 정리하겠습니다.

[vkehfdl1]

감사합니다. 우선은 step 2(SRTrain broad re-check)를 먼저 진행해 주시는 쪽이 좋겠습니다.

이유는 간단합니다.

• 이 저장소의 공식 지원 경로는 여전히 SRTrain-first 이고,
• 지금 가장 먼저 분리해야 하는 질문도 “브라우저 자동화 문제인가?”보다 “SRTrain/search 단계 자체가 queue/empty로 흔들리는가?” 이기 때문입니다.

그래서 우선순위는 아래처럼 잡는 게 좋겠습니다.

1. Step 2 우선 진행
   • 여러 시작 시각/날짜대에서 FOUND N, FOUND 0, queue 메시지, WRG000000 같은 결과를 표로 정리
   • 가능하면 동일 조건 반복 시 결과가 흔들리는지도 함께 기록
   • 쿼리 파라미터(출발/도착/날짜/시각), 실행 시각, 응답 요약을 같이 남겨 주세요
2. Step 3(storageState capture)는 일단 보류
   • 이건 지원 경로 검증보다는 브라우저 진단에 가깝습니다
   • 정말 필요해지면 그때 진행하되, storageState 파일/세션 쿠키 자체는 이슈에 업로드하지 말고, 로컬에서만 재현 비교용으로 써 주세요

즉, 지금은 SRTrain 경로에서 재현성이 있는지 확인하는 증거 수집이 가장 가치가 큽니다. 그 결과를 보면:

• SRTrain 경로 자체가 불안정하면 → 별도 하위 버그로 좁혀서 추적
• SRTrain 경로는 상대적으로 정상인데 브라우저 자동화만 흔들리면 → docs에 “unsupported/brittle” 성격을 더 분명히 적는 쪽으로 정리

정리하면: 지금 당장은 step 2부터 부탁드립니다. step 3은 후속 진단 카드로 남겨 두겠습니다.

[vkehfdl1]

재현 결과 공유 감사합니다. 이 sweep 결과는 꽤 유의미합니다.

지금 보이는 패턴만 놓고 보면,

• 일부 시간대(00:00 / 06:00 / 09:00)에는 조회가 되고,
• 같은 날짜의 다른 시간대(12:00 이후 다수)에서는 FOUND 0 또는 WRG000000 로 떨어지며,
• 그 사이에 queue 메시지도 반복된다는 점에서,

적어도 이 이슈를 “결과 DOM에서 특정 열차 행을 못 찾는 프론트엔드 셀렉터 문제” 하나로 축소해서 보기 어렵다는 근거가 더 강해졌습니다. 즉, 현재는 검색 단계 응답 자체가 흔들리거나 분기되고 있다는 쪽에 무게가 실립니다.

이 관찰은 이 저장소 쪽 다음 판단에도 도움이 됩니다.

• srt-booking 문서에는 queue / empty / WRG000000 를 단순 매진 또는 열차 없음과 동일시하면 안 된다는 점을 명시할 필요가 있습니다.
• 반대로, 아직은 이 결과만으로 특정 anti-bot 헤더/쿠키/지문 조건을 저장소 차원에서 안내할 근거는 부족합니다.
• 따라서 우선 조치는 계속 docs/troubleshooting 강화가 맞고, Playwright 셀렉터 보강은 우선순위를 뒤로 두는 게 타당해 보입니다.

현재 기준으로는 아래 정도를 문서화 후보로 보겠습니다.

1. 동일 날짜/구간에서도 조회 시각에 따라 결과 수가 크게 달라질 수 있음
2. FOUND 0 / queue / WRG000000 는 upstream transient 또는 session-level gating 가능성을 포함함
3. 브라우저 자동화는 진단용일 수는 있어도 공식 지원 경로는 SRTrain-first 임
4. 이슈 제보 시에는 start time sweep 결과와 실행 시각을 함께 첨부하는 것이 유용함

이 정도 증거면, 이 이슈는 계속 문서/트러블슈팅 범위로 유지하되, SRTrain 경로 자체의 응답 불안정성은 별도 하위 버그로 분리할지 검토할 수 있겠습니다. 추가로 같은 조건을 짧은 간격으로 반복했을 때 결과가 바뀌는지까지 보이면, session gating / transient 쪽 판단에 더 도움이 될 것 같습니다.

[vkehfdl1]

SRTrain 라이브러리 문제로 보이는데 버그를 케이스킬 선에서 픽스 가능한지 확인 바람

[vkehfdl1]

현재까지 나온 재현만 기준으로 보면, 원인이 SRTrain 쪽에 있을 가능성은 충분히 있어 보이지만, k-skill 레이어에서 “근본 픽스”할 수 있는 범위는 제한적입니다.

정리하면:

• k-skill의 srt-booking은 기본적으로 SRTrain을 감싸는 thin wrapper / usage guide 성격에 가깝습니다.
• 그래서 SRTrain 내부에서 SRT 쪽 응답(queue / empty / WRG000000)을 잘못 해석하거나, upstream 변경을 못 따라가고 있다면, 가장 정확한 fix 지점은 SRTrain 자체일 가능성이 큽니다.
• 반면 k-skill 쪽에서도 아예 할 수 있는 일이 없는 건 아닙니다.

k-skill 선에서 가능한 대응은 대략 이 정도입니다.

1. 문서 보강
   • queue / empty / WRG000000 를 정상적인 “열차 없음”으로 단정하지 않도록 안내
   • 지원 범위와 한계를 분명히 적기
2. 방어적 래핑
   • 특정 응답을 만나면 즉시 실패로 끝내지 않고, “upstream transient / session gating 가능성”으로 분류해서 더 좋은 에러 메시지를 주기
   • bounded retry / evidence collection 가이드를 붙이기
3. 하위 버그 분리
   • 재현 스크립트와 함께 “SRTrain upstream bug suspected” 형태로 별도 트래킹하기

반대로, 아래는 k-skill만으로 해결하기 어렵습니다.

• SRTrain 내부 파싱/요청 로직 자체 수정
• SRT 측 응답 포맷/정책 변경 대응
• 라이브 웹사이트의 anti-bot / queue 분기 자체 우회

그래서 제 판단은 이렇습니다.

• k-skill 선에서 완화(mitigation)와 가시성 개선은 가능합니다.
• 하지만 실제 원인이 SRTrain 내부 버그라면 최종 fix는 upstream(SRTrain) 패치가 필요할 가능성이 높습니다.

즉, 이 이슈에서는 우선 k-skill 쪽에선 문서/에러처리/트러블슈팅을 정리하고, 동시에 재현 가능한 최소 케이스를 만들어 SRTrain upstream issue 후보로 분리하는 방향이 가장 현실적입니다.