fix: paginate GitHub trees on truncation to avoid silently dropping files#60
Merged
Merged
Conversation
…iles list_github_files fetched the full repo tree in a single recursive Trees API call. On very large repos GitHub sets truncated:true and returns a partial tree; semcode logged a warning and indexed the partial set, so an unknown subset of files was silently absent from the index. Now the truncated case falls back to a recursive per-subtree walk using non-recursive git/trees/<sha> calls (each listing stays well under the size limit), pruning subtrees outside root and fetching siblings concurrently. Shared filter logic is extracted so both paths behave identically. Closes #55 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
list_github_files(server/indexer/github_source.py) fetched the entire repo tree in a single GitHub Trees API call withrecursive=1. The Trees API has an undocumented response-size limit; on very large repos GitHub setstruncated: trueand returns only a partial tree. semcode detected this but only logged a warning and then iterated over whatever partial tree it got back — so an unknown subset of files was silently absent from the index run (never parsed, embedded, or upserted, and thus unsearchable).Closes #55
Fix
Keep the fast path (one
recursive=1call) for the common case. When the response is truncated, fall back to a recursive per-subtree walk using non-recursivegit/trees/<sha>calls — each single-directory listing is tiny and effectively never hits the size limit. This reuses git blob SHAs directly (exactly whatGitHubFile.blob_shaneeds for incremental indexing), so no API-shape changes are required._filter_tree_blobs()— extracted shared filter helper (root prefix / supported extension / exclude) so the fast path and fallback filter identically._walk_tree_recursive()— walksgit/trees/<sha>per directory, joins full paths from per-level entry names, prunes subtrees outsideroot, and fetches siblings concurrently via anasyncio.Semaphore(_TREE_WALK_CONCURRENCY = 10, mirroring_DIFF_CONCURRENCY). Seeds from the root tree SHA already present in the truncated response — no extra ref-resolution round-trip._subtree_is_relevant()— the root-prefix pruning predicate.Tests
New
tests/test_github_source.py(respx-mocked):rootare never fetchedFull suite green (208 passed).
Docs
docs/ingestion.md— replaced the "Large-repo warning" (silent drop) note with a description of the new fallback.🤖 Generated with Claude Code