fix(ci): test suite hangs on CI and burns the full 6h limit — CodeLens CI has not gone green in 60+ runs, no timeout-minutes anywhere

[Wolfvin]

Mengapa (falsifiable — diverifikasi 2026-07-17)

Gate CI CodeLens mati total, dan sudah mati berhari-hari. Tak ada yang menyadarinya karena kegagalannya diam.

gh run list --workflow "CodeLens CI" --limit 60 → NOL sukses. Semua cancelled, mundur setidaknya sampai 2026-07-14.

cancelled itu menyesatkan — tak ada manusia yang membatalkannya. Buktinya durasi:

run 29502899082: created=2026-07-16T13:36:17Z  updated=2026-07-16T19:36:35Z  conclusion=cancelled

6 jam 0 menit 18 detik — itu batas keras job GitHub. Job-nya hang sampai dibunuh platform, lalu ditandai cancelled.

Di mana hang-nya (run 29555933312, PR #298, diperiksa saat masih hidup):

Step	Status
1. Set up job	✅ 04:53:23Z
2. Checkout repository	✅ 04:53:24Z
3. Set up Python 3.11	✅ 04:53:25Z
4. Install dependencies	✅ 04:53:25Z
5. Run test suite	in_progress sejak 04:53:30Z — 64+ menit dan terus

Runner nyata ter-assign (GitHub Actions 1000009177), bukan antri. Suite yang sama selesai 346 detik di Windows lokal, dan daftar kegagalannya stabil (19, identik dengan main).

Diperparah: grep -rn "timeout-minutes" .github/workflows/ → kosong. Tak satu pun workflow punya timeout. Jadi setiap hang membakar 6 jam penuh menit Actions sebelum mati, dikali CodeLens CI + CodeLens Quality Gate (4 matriks Python) + CodeLens SARIF per push.

Konteks

• Dampak paling serius: gate merge-nya fiktif. PR fix(parser): extract Python module-level calls (closes #291) #292, fix(dead-code): count JSX prop function references as usage (closes #294) #295, test(audit): add dedicated test suite for a11y sub-check (follow-up #256) #296 semua di-merge tanpa CI pernah hijau. Yang menahan kualitas selama ini cuma run lokal manual.
• Log tidak bisa dibaca saat job in_progress (BlobNotFound) dan saat job dibunuh di 6 jam log-nya juga tak berguna — tanpa timeout-minutes tak ada cara mendiagnosis hang-nya. Ini yang bikin masalahnya awet: setiap investigasi butuh nunggu 6 jam untuk log yang lalu hilang.
• CodeLens SARIF gagal terpisah di setiap run main termasuk 61d70a8 (tip main sekarang) — bug lain, jangan dicampur.
• Hang-nya spesifik Linux/CI: lokal (Windows) tidak hang. Kandidat yang belum diverifikasi: test LSP menunggu server yang tak pernah menjawab (bandingkan catatan ENV LIMIT rust-analyzer), atau tree-sitter native (lihat fix(ci): pin tree-sitter<0.26 to stop native segfault (#235) #266 pin <0.26 karena segfault, dan fix(parser): make python_parser.py keep_alive strategy tree-sitter 0.26-safe #267).
• Terkait tapi BUKAN duplikat: audit(ci): triage 13 test failures unmasked by segfault fix (#266) #271 mentriase 19 test yang gagal; issue ini soal suite yang tak pernah selesai di CI.

Tujuan

CI gagal cepat dan terbaca, bukan hang 6 jam lalu diam — sehingga hang-nya bisa didiagnosis dan gate merge kembali berarti.

Constraint

• timeout-minutes BUKAN fix root cause — ia guard yang membuat hang terlihat dan murah. Jangan tutup issue ini hanya karena timeout ditambahkan; hang-nya harus diketahui penyebabnya.
• Ambil batas dari fakta terukur: suite lokal 346 detik. Batas job yang longgar tapi waras (mis. 20-30 menit) mengubah kebakaran 6 jam jadi kegagalan cepat berlog.
• Jangan mask hang dengan menghapus/skip test sampai penyebabnya diketahui — itu menukar gate palsu dengan gate palsu yang lain.
• pytest-timeout tidak terpasang (--timeout → unrecognized arguments). Kalau dipakai untuk melokalisasi test yang hang, tambahkan sebagai dev-dep secara eksplisit.

Definition of Done

• Semua workflow punya timeout-minutes; run yang hang mati dalam menit, bukan 6 jam, dan log-nya terbaca
• Step/test persis yang hang di Linux teridentifikasi dari log, dan ditulis di issue ini
• Root cause hang diketahui dan diperbaiki (atau di-skip dengan alasan tertulis + issue lanjutan kalau lingkungan CI memang tak mendukungnya)
• CodeLens CI menyelesaikan satu run sampai conclusion nyata (success/failure) — bukan cancelled
• Kegagalan CI yang tersisa cocok dengan baseline lokal (19, sesuai audit(ci): triage 13 test failures unmasked by segfault fix (#266) #271), bukan angka misterius

[Wolfvin]

Bukti hidup — run PR #298 dipantau 70 menit penuh

Monitor dipasang di run 29555933312 selama 1 jam penuh: nol event. Step 5 tak pernah bergerak.

job=Test Suite  status=in_progress  started=2026-07-17T04:53:23Z
hung step: 5. Run test suite since 2026-07-17T04:53:30Z
now=2026-07-17T06:03:21Z

70 menit dan terus jalan, untuk suite yang selesai 346 detik di lokal — 12× lipat dan belum berhenti, menuju pembunuhan 6 jam seperti run-run sebelumnya.

Ini mengoreksi catatan CONTEXT.md yang menyebut "CI runner infrastructure DEGRADED / backlog". Diagnosis itu salah: runner-nya sehat dan ter-assign sejak detik pertama (GitHub Actions 1000009177), step 1-4 semuanya beres dalam 5 detik. Yang bermasalah bukan antrian runner — suite-nya sendiri yang tak pernah selesai di Linux. Selama ini disalahartikan sebagai lambat, bukan hang.

[Wolfvin]

✅ Pelakunya bernama — cap-nya bekerja pada percobaan pertama

Run pertama dengan timeout-minutes + pytest-timeout (PR #304, run 29559723083): selesai ~2 menit, bukan 6 jam, dan langsung menunjuk test-nya.

timeout: 120.0s / timeout method: thread
../tests/test_hybrid_engine.py ...........+++ Timeout +++
  File "/home/runner/work/CodeLens/CodeLens/tests/test_hybrid_engine.py", line 95,
       in test_query_confidence_without_deep
    stdout, stderr = process.communicate(input, timeout=timeout)
    ready = selector.select(timeout)
    fd_event_list = self._selector.poll(timeout)

Satu test membakar 6 jam × ratusan run selama berhari-hari: TestHybridIntegration::test_query_confidence_without_deep (tests/test_hybrid_engine.py:95).

def test_query_confidence_without_deep(self):
    result = subprocess.run(
        [sys.executable, os.path.join(SCRIPT_DIR, "codelens.py"),
         "query", "detect_dead_code", CODELENS_ROOT, "--format", "json"],
        capture_output=True, text=True          # <-- tidak ada timeout=
    )

subprocess.run tanpa timeout= = tunggu selamanya. Itu yang mengubah "anak macet" jadi "CI 6 jam". Tetangganya (test_impact_confidence_without_deep, test_lsp_status_cli) punya pola yang sama.

Yang sudah diverifikasi vs yang BELUM

Terverifikasi (dijalankan):

• Hang di Linux CI, di communicate() menunggu EOF anak.
• Tidak tereproduksi di Windows lokal: perintah CI persis (cd scripts && pytest ../tests/ ...) selesai 160 detik, 19 gagal / 2541 lolos.
• query adalah command valid (hidden — bagian dari 13 hidden-pending chore(commands): evaluate and resolve 13 hidden-pending commands #200). Jalan lokal, exit 0, output {"status":"ok"...}. Jadi ini bukan invalid-choice.
• pygls + lsprotocol terpasang di lokal juga → bukan pembeda lokal-vs-CI.
• Hipotesis "anak LSP bocor menahan pipe warisan" GUGUR: lsp_client.py:246 sudah Popen(..., stdin=PIPE, stdout=PIPE, stderr=PIPE) — anaknya tak mewarisi stdio test.
• _which() (lsp_client.py:78) memanggil which — perintah POSIX. Perilaku deteksi LSP jelas berbeda antara runner Linux dan Windows.

BELUM diketahui — jangan tebak, ini yang harus dikerjakan:

• Kenapa proses anak tak pernah keluar di Linux. Kandidat: codelens.py query mendeteksi LSP di runner (_which sukses di Linux), lalu initialize() menunggu server yang tak pernah menjawab — bandingkan catatan ENV LIMIT rust-analyzer. Belum dibuktikan.
• Apakah ini bug test (subprocess tanpa timeout) atau bug produk (CLI menggantung saat LSP terdeteksi tapi tak responsif). Kalau yang kedua, user sungguhan yang menjalankan codelens query di mesin ber-LSP ikut menggantung — itu jauh lebih serius daripada CI merah.

Konsekuensi untuk DoD issue ini

Menambahkan timeout= ke test = menyembunyikan gejala kalau CLI-nya sendiri yang menggantung. Root cause harus dijawab dulu: jalankan codelens.py query detect_dead_code . --format json di Linux ber-LSP dan lihat apakah CLI-nya sendiri yang tak pernah selesai.

Catatan: setelah PR #304, CodeLens CI akan merah, bukan hang. Itu kemajuan — merah jujur mengalahkan gate fiktif.