refactor(code-nav): consume codeIndexState, drop deprecated indexingStatus - #23
Merged
Conversation
…tatus The backend deprecated `indexingStatus: IndexingStatus` in favour of `codeIndexState: CodeIndexState` across every code-navigation result type (searchSymbols, listRepoFiles, fetchCodeContext, grepRepoFile, plus several we don't consume). Legacy field still served. Defensive migration ahead of removal, same shape as the `pkg deps` typed-field swap in PR #22. The enums are near-identical on the wire: - `INDEXED` → `CURRENT` (same happy-path semantics). - `INDEXED` → `STALE` is a new lifecycle state — results were served but the navpack is older than VersionManifest and a reindex is enqueued. We treat it as happy-path, same as `CURRENT` / legacy `INDEXED`. - `INDEXING` / `PENDING` / `FAILED` / `NOT_FOUND` / `UNRESOLVABLE` values are unchanged. Our sentinel checks (`=== "INDEXING"` and `=== "UNRESOLVABLE"`) continue to fire on the same string values; string comparison logic is unchanged. Changes: - All four GraphQL queries select `codeIndexState` instead of `indexingStatus`. Zod schemas renamed accordingly. - `throwIfIndexing` helper and `searchSymbols` inline sentinel swap to reading `codeIndexState`. All consumers still gated on the same values. - Test fixtures migrate from `indexingStatus: "INDEXED"` → `codeIndexState: "CURRENT"`; `indexingStatus: "INDEXING"` → `codeIndexState: "INDEXING"`. - Doc comments on the response-builder modules updated to reference the new field name. No envelope shape change. `codeIndexState` is consumed internally only — never surfaced on the `list_files` / `read_file` / `grep_file` / `search_symbols` envelopes. `STALE` results served today flow through identically (we never branched on the absence of a staleness indicator); future UX work could surface an "index being refreshed" note in verbose mode, but that's out of scope. Live-smoke: all four indexing-gated tools (`code files`, `code read`, `code grep`, `code search`) verified against production pkgseer on `npm:express`. CURRENT state rendered as happy-path; INDEXING retry (`code search … --wait 30`) still promotes to the typed error and resolves on retry.
…ndexState Follows the field rename landed in this PR's main commit. The tools.md paragraph described the success-sentinel shape as `indexingStatus`; updated to `codeIndexState: "INDEXING"` to match what the service layer actually reads off the wire now.
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.
Summary
Defensive swap from
indexingStatus: IndexingStatus(backend-@deprecated) tocodeIndexState: CodeIndexStateacross every code-navigation GraphQL result we read. Same shape as PR #22 (pkg depstyped fields): read the non-deprecated field while the legacy one is still served, so the CLI keeps working when the backend eventually removes it.What changed on the wire
searchSymbols { … indexingStatus }searchSymbols { … codeIndexState }listRepoFiles { … indexingStatus }listRepoFiles { … codeIndexState }fetchCodeContext { … indexingStatus }fetchCodeContext { … codeIndexState }grepRepoFile { … indexingStatus }grepRepoFile { … codeIndexState }Enum mapping
IndexingStatus(old)CodeIndexState(new)INDEXEDCURRENTSTALECURRENT.INDEXINGINDEXINGPENDINGPENDINGFAILEDFAILEDNOT_FOUNDNOT_FOUNDUNRESOLVABLEUNRESOLVABLEThe CLI's two string checks (`=== "INDEXING"` and `=== "UNRESOLVABLE"`) fire on identical values in both enums — no behavioural change.
Scope
No envelope shape change. `codeIndexState` is consumed internally — never surfaced on any tool's envelope. `STALE` flows through identically to `CURRENT` today; future UX work could surface an "index being refreshed" note under `--verbose`, but that's a separate ticket.
Testing
Live-smoke (production pkgseer)
All four indexing-gated tools verified on `npm:express`:
Test plan
🤖 Generated with Claude Code