Repository navigation
query: answer mid-edit at once, and index the no-caller lookups - #1864
Merged
Merged
Conversation
A query whose answer touched a file edited since the graph was built waited up to AXIOMCODE_FRESH_WAIT (default 30 s) for the background rebuild. On a 1,300-file Java repository an agent asking about the code it was editing waited 20-33 s per query, though the answer from the previous graph already marks those rows and names the files it predates. The default is now 0: answer at once; --fresh still waits. impact spent 1.2 s of 1.8 s finding why a method has no callers: the bases written in a type's header were read from type_refs by file and line, and a partial type's parts from symbols by qualified name, neither indexed. Two indexes take impact to 0.5-0.75 s with byte-identical answers on five targets; the graph grows 4%. Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
swapnilpaliwal-sd
requested review from
JaredHLZhang,
Whua689 and
suyashpaliwal26
as code owners
October 8, 2026 16:37
swapnilpaliwal-sd
added a commit
that referenced
this pull request
Oct 8, 2026
Node ≥ 22.13 in the badge and Requirements (#1865). The refresh paragraph still said a query waits up to AXIOMCODE_FRESH_WAIT (default 10) seconds; since #1864 it answers from the previous graph at once, with the rows in edited files marked, and --fresh waits. Committed with --no-verify (approved for this PR): the term check matches content already in README.md, none of it in these lines. Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.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
1 participant
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.
Symptoms
AXIOMCODE_FRESH_WAIT(default 30 s) for the background rebuild. Replaying an agent's edits on a 1,300-file Java repository, every query about the code being edited took 20–33 s, although the answer from the previous graph already marks the rows in edited files and names the files it predates.impacttook 1.8 s, 1.2 s of it inno_caller_reasons→library_bases/type_parts, which readtype_refsby file + line andsymbolsby qualified name, neither of them indexed (65k-row scans per type).Change
AXIOMCODE_FRESH_WAITdefaults to 0: the query answers from the previous graph at once, with itsgraph refresh:line and marked rows.--fresh(MCPfresh=true) still waits; setting the variable restores a wait.axiomcode-indexaddstype_refs(file, line)andsymbols(qualified_name).Evidence (1,300-file Java repository)
impact, five targets, fresh graphtests/freshness.py: 118 of 118 pass.tests/refresh.py --lang java: the same 8changed-reporting failures as on the unmodified integration branch, none new.Not in this PR
out/dl/impactis stamped with the live graph's mtime, so warming the next graph early would invalidate the one being read.