Skip to content

fix: sync __version__ to 0.7.1 and guard None git ref in incremental update#1

Closed
andyx5-26 wants to merge 1 commit intoMibayy:mainfrom
andyx5-26:main
Closed

fix: sync __version__ to 0.7.1 and guard None git ref in incremental update#1
andyx5-26 wants to merge 1 commit intoMibayy:mainfrom
andyx5-26:main

Conversation

@andyx5-26
Copy link
Copy Markdown

Changes

__init__.py

__version__ was hardcoded as 0.4.2, out of sync with pyproject.toml which declares 0.7.1. This causes token_savior.__version__ to return wrong value at runtime.

server.py_maybe_incremental_update()

The function called get_changed_files(slot.root, idx.last_indexed_git_ref) without checking if last_indexed_git_ref is None first. get_changed_files() already handles None by returning an empty changeset (safe), but this meant the incremental update path would silently skip forever on repos where the initial index didn't record a git ref (empty repo, non-standard git setup). Now triggers a full rebuild in that case so a ref gets recorded.


Spotted while evaluating the project.

- __init__.py: bump __version__ from 0.4.2 to 0.7.1 to match pyproject.toml
- server.py: add guard in _maybe_incremental_update() for when
  last_indexed_git_ref is None (empty repo / first index without git ref).
  Previously relied on get_changed_files() returning empty changeset for
  None ref, which worked but silently skipped re-indexing forever. Now
  triggers a full rebuild so a git ref gets recorded for future checks.
Copy link
Copy Markdown
Owner

@Mibayy Mibayy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the report — the problem you identified in _maybe_incremental_update is real, but I can't merge either change as-is.

__init__.py — version is now stale

The repo has since been bumped to v0.9.0 (commits 4b5f622 and b30bfe1). Merging 0.7.1 here would be a regression.

server.py — fix introduces an infinite rebuild loop

The problem you spotted is genuine: if last_indexed_git_ref is None, the incremental path silently stays a no-op forever. However, the proposed fix (_build_slot on every hit) has a new bug:

On a git repo with no commits yet (git init but nothing committed), is_git_repo() returns True but get_head_commit() returns None. So:

  1. _maybe_incremental_updatelast_indexed_git_ref is None → calls _build_slot
  2. _build_slot → full index → get_head_commit() still None → ref stays None
  3. 30 seconds later → same thing → full rebuild loop forever

The correct fix is minimal — just stamp HEAD onto the index without rebuilding:

if idx.last_indexed_git_ref is None:
    head = get_head_commit(slot.root)
    if head is not None:
        idx.last_indexed_git_ref = head
        _save_cache(idx)
    return

This correctly handles all cases:

  • Normal git repo with commits → ref gets recorded, future incremental updates work
  • Empty repo (no commits) → head is None → we return without looping
  • Non-git → already blocked by if not slot.is_git at the top of the function

Mibayy pushed a commit that referenced this pull request Apr 5, 2026
If the initial index ran before the first commit (or the cache was
written by an older version), last_indexed_git_ref is None and the
incremental update path silently stays a no-op forever.

Fix: when last_indexed_git_ref is None, fetch HEAD and persist it as
the new baseline so future incremental checks work correctly.

If HEAD is also None (empty repo, no commits yet), do nothing and
return — avoids the full-rebuild loop that the naive _build_slot fix
would cause (firing every 30 s indefinitely).

Refs: PR #1 (proposed full rebuild — rejected due to infinite loop risk)

Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
@Mibayy
Copy link
Copy Markdown
Owner

Mibayy commented Apr 5, 2026

Applied the correct fix directly in 3c756f1 — stamps HEAD onto the index without triggering a rebuild, with a None-guard for empty repos. Thanks for spotting the issue.

@Mibayy Mibayy closed this Apr 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants