Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

getDominantFile returns null when test or generated files fill its 20-row window

Open
  • Is something wrong?
#2,578 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
Half a day
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
sql, typescript
Domain
databases

Research direction

Start in src/db/queries.ts at computeDominantFile and its LIMIT 20 query, then getTopRouteFile, which has the same truncate-then-filter shape. The consumer is the edgeCount >= 3 * nextEdgeCount check in src/context/index.ts. Reproduce with the 60-function src/core.ts chain and 20 tests/tN.test.ts files; done when getDominantFile() returns src/core.ts with edgeCount 60 and nextEdgeCount 50 instead of null.

Written by the indexing model from the issue text.

Description

Summary

computeDominantFile takes the top 20 files by in-file edge count in SQL (LIMIT 20), and only then drops test and generated files in code. When 20 or more low-value files outrank the real code, nothing is left and it returns null, even though a clear dominant file exists. With fewer than 20 such files, nextEdgeCount can be understated, because the runner-up was cut off by the limit. That affects the edgeCount >= 3 * nextEdgeCount check that decides the directory boost.

Reproduction (verified)

On main at c71a3d03, built from source, Linux (WSL2), Node 22.22.2.

  • src/core.ts has a chain of 60 functions, each calling the next (60 in-file edges), and src/second.ts has a chain of 50.
  • 20 files tests/tN.test.ts each have a chain of 70.
const cg = await CodeGraph.init(dir, { index: true });
(cg as any).queries.getDominantFile(); // → null

Expected: { filePath: 'src/core.ts', edgeCount: 60, nextEdgeCount: 50 }.

Generated code makes this plausible in real repos. Android R.java per module, protobuf *OuterClass.java / *Grpc.java, and test-heavy monorepos could fill the window.

Same pattern (inferred, not reproduced)

getTopRouteFile takes the 20 files with the most routes, then filters. Both totalRoutes and the 30% share check are computed on the truncated, filtered set.

Possible fix

Push the test-path exclusion into SQL, or keep fetching past 20 rows until 20 rows survive the filter (or the rows run out). The generated-file check needs the files table, so the second option may be simpler.

Related

#2575 (the plan fix for the same query, #2571), and #2349 / #2115, which cache the result. None of them changes the window.

Dominant language
C
Stars
73.2k
Forks
4.7k
Avg merge
2h 16m
Merged PRs (30d)
423

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from colbymchenry/codegraph

All issues in colbymchenry/codegraph

Similar issues

More C issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.