impact/path: one facts export per graph, however many queries arrive at once - #1850
Merged
Merged
Conversation
…at once The export had no lock: a query that found the stamp stale while another process was already writing the same facts (the background warm-up after index, a second query, several hooks at once) ran the whole export again beside it. Measured on an 8,619-file Java repository: the first query after index cost 193 s against 8.8 s warm, and every concurrent query paid the same again while thrashing the writer. The first comer now takes <facts>/.exporting and the others wait for its stamp, then answer from the facts it wrote; a lock whose writer is gone is taken over. tests/export_singleflight.py pins the wait, the takeover and the unlock. Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
…library staging A name no graph declares, reached only by text, whose lines include an import of it is the signature of an unstaged dependency — until now the answer was indistinguishable from an engine gap, and the fix is one flag away. One hint line under the [text] rows, only for undeclared names. 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 3, 2026 00:08
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.
Two agent-experience fixes measured on an 8,619-file Java repository.
One facts export per graph. The export the first query pays had no lock: a query that found the stamp stale while another process was already writing the same facts — the background warm-up
indexstarts, a second query, several hooks at once — ran the whole export again beside it. Measured: the first query afterindexcost 193 s (107 s user + 77 s sys of thrash) against 8.8 s warm, and every concurrent query paid the same again. Now the first comer takes<facts>/.exporting, the others wait for its stamp and read what it wrote, and a lock whose writer died is taken over. Re-measured with the lock: the racing query spends 6 s user + 2.5 s sys waiting instead of re-exporting, and no lock is left behind.An undeclared name that arrives through an import hints at staging.
impact ApplicationContexton a repo without the dependency staged answers honestly ([name match], by-name rows) but gave no way out; it is the commonest setup gap and looks exactly like an engine gap. One hint line under the [text] rows now names the fix:axiomcode index --library <its source dir>.Tests: new
tests/export_singleflight.pypins the wait (a held lock makes a stale--warmwait and NOT re-export — the holder's stamp survives untouched), the takeover (a dead writer's lock is removed and the export runs) and the unlock. Also run: java cases 329/329, typescript 225/225, facts_cache, latency, freshness, refresh_races, front_door — all green.