Mengapa
Ditemukan dogfooding codelens audit di repo nyata (Coretax-Auto-Downloader,
vps-deploy-kaw81/api/, ~29K baris TS/Express). registry_dead mengklaim
verifyWebqrisSignature (routes/webhooks.ts:36) punya 0 referensi. Verifikasi
manual: fungsi itu DIPANGGIL di baris 194, 246, 563 (3 call site nyata, salah
satunya HMAC signature verifier untuk webhook pembayaran — false-positive di
sini kelas security-relevant, bukan cosmetic).
Bukti (SQL langsung ke .codelens/codelens.db, bukan asumsi)
SELECT source_id, target_id, edge_type, line FROM graph_edges
WHERE file LIKE '%webhooks.ts%' ORDER BY line LIMIT 10;
('routes\webhooks.ts:30', None, 'CALLS', 0)
('routes\webhooks.ts:30', None, 'CALLS', 0)
('routes\webhooks.ts:30', None, 'CALLS', 0)
('routes\webhooks.ts:30', None, 'CALLS', 0)
('routes\webhooks.ts:30', None, 'CALLS', 0)
5 baris identik, target_id selalu NULL, line selalu 0. source_id
= routes\webhooks.ts:30 — bukan format konvensi <file>:0:<module>
yang sudah mapan untuk synthetic module-level caller (issue #223, dipakai
is_module_level_source_id() di graph_model.py). Baris 30 di file asli
adalah const WEBQRIS_WEBHOOK_SECRET = process.env... — bukan lokasi call
apapun.
Konteks Kode
Call site persis:
webhookRouter.post('/qris', asyncHandler(
async (req: Request, res: Response) => {
// ...
if (!verifyWebqrisSignature(rawBody, signature)) { ... }
},
'WEBHOOK_QRIS',
));
Call ke verifyWebqrisSignature ada di dalam arrow function yang jadi
argumen pertama dari asyncHandler(...), yang sendiri adalah argumen
kedua dari webhookRouter.post(...).
Sudah Dicoba Repro (BELUM berhasil isolasi minimal)
2 percobaan repro minimal di fixture terisolasi — keduanya TIDAK
reproduce bug ini (fungsi ter-resolve dengan benar, ref_count > 0):
- Pattern sederhana:
router.post(path, async (req,res) => { fn() }).
- Pattern lebih dekat:
router.post(path, asyncHandler(async (req,res) => { fn() }, 'LABEL')) dengan asyncHandler didefinisikan lokal di fixture.
Artinya bug butuh kondisi tambahan yang belum ke-isolasi — kemungkinan
terkait ukuran file (webhooks.ts asli 200+ baris, banyak import), atau
interaksi dengan fungsi/pattern lain di file yang sama, atau state parser
yang cuma muncul di scan workspace besar (bukan single-file scan). _find_module_level_calls
(ts_backend_parser.py:507) di baca sekilas — secara desain SEHARUSNYA
menangkap call ini (tidak skip subtree arrow_function yang bukan
registered variable_declarator value), jadi kemungkinan bug ada di tahap
SESUDAH ekstraksi call (edge resolution / graph_model.populate_graph_tables()),
bukan di ekstraksi call itu sendiri.
Beda dari Issue #220
Ini BUKAN kasus #220 (same_file_usages exemption) — itu untuk simbol yang
DIREFERENSI tapi tidak DIPANGGIL (const/static). verifyWebqrisSignature
genuinely DIPANGGIL dengan (), di file yang sama, harusnya kena jalur
_find_module_level_calls normal, bukan jalur exemption.
Definition of Done
Mengapa
Ditemukan dogfooding
codelens auditdi repo nyata (Coretax-Auto-Downloader,vps-deploy-kaw81/api/, ~29K baris TS/Express).registry_deadmengklaimverifyWebqrisSignature(routes/webhooks.ts:36) punya 0 referensi. Verifikasimanual: fungsi itu DIPANGGIL di baris 194, 246, 563 (3 call site nyata, salah
satunya HMAC signature verifier untuk webhook pembayaran — false-positive di
sini kelas security-relevant, bukan cosmetic).
Bukti (SQL langsung ke
.codelens/codelens.db, bukan asumsi)5 baris identik,
target_idselaluNULL,lineselalu0.source_id=
routes\webhooks.ts:30— bukan format konvensi<file>:0:<module>yang sudah mapan untuk synthetic module-level caller (issue #223, dipakai
is_module_level_source_id()digraph_model.py). Baris 30 di file asliadalah
const WEBQRIS_WEBHOOK_SECRET = process.env...— bukan lokasi callapapun.
Konteks Kode
Call site persis:
Call ke
verifyWebqrisSignatureada di dalam arrow function yang jadiargumen pertama dari
asyncHandler(...), yang sendiri adalah argumenkedua dari
webhookRouter.post(...).Sudah Dicoba Repro (BELUM berhasil isolasi minimal)
2 percobaan repro minimal di fixture terisolasi — keduanya TIDAK
reproduce bug ini (fungsi ter-resolve dengan benar,
ref_count > 0):router.post(path, async (req,res) => { fn() }).router.post(path, asyncHandler(async (req,res) => { fn() }, 'LABEL'))denganasyncHandlerdidefinisikan lokal di fixture.Artinya bug butuh kondisi tambahan yang belum ke-isolasi — kemungkinan
terkait ukuran file (webhooks.ts asli 200+ baris, banyak import), atau
interaksi dengan fungsi/pattern lain di file yang sama, atau state parser
yang cuma muncul di scan workspace besar (bukan single-file scan).
_find_module_level_calls(
ts_backend_parser.py:507) di baca sekilas — secara desain SEHARUSNYAmenangkap call ini (tidak skip subtree arrow_function yang bukan
registered variable_declarator value), jadi kemungkinan bug ada di tahap
SESUDAH ekstraksi call (edge resolution /
graph_model.populate_graph_tables()),bukan di ekstraksi call itu sendiri.
Beda dari Issue #220
Ini BUKAN kasus #220 (same_file_usages exemption) — itu untuk simbol yang
DIREFERENSI tapi tidak DIPANGGIL (const/static).
verifyWebqrisSignaturegenuinely DIPANGGIL dengan
(), di file yang sama, harusnya kena jalur_find_module_level_callsnormal, bukan jalur exemption.Definition of Done
syarat sebelum fix, supaya ada regression test yang benar-benar
menangkap kasus ini (2 percobaan repro di atas GAGAL, jangan ulang
pattern yang sama).
test_graph_accuracy_golden.py(harness yangsudah ada untuk kelas bug false-dead serupa — fix(callgraph): extract module-top-level calls to fix rc undercount (closes #210) #219/fix(dead-code): same-file-usage tracking missing for 14 languages, causes false-positive registry_dead #220/fix(callgraph): arrow functions as object-literal values not tracked, undercounts ref_count #222/fix(trace,impact): module-level callers invisible due to synthetic source_id, inconsistent with rc #223/fix(callgraph): calls inside asyncHandler-wrapped route handlers missing from graph_edges #231).
verifyWebqrisSignature(atau fungsi analog difixture) > 0 setelah fix, dan full test suite tanpa regresi baru.