Skip to content

IndexerService follow-ups: auto-resume index dir, reopen-modal chain context, stale config/chain edges #59

Description

@ben-dev-au

Pre-existing behaviours in the indexer lifecycle (now fnd/tui/indexer_service.py), surfaced by review on #49#53 and deferred to keep the decomposition PRs pure relocation:

  1. Auto-resume bypasses the app's index dir. maybe_resume() starts with index_dir=default_index_dir() while every other path honours self._app._index_dir (and on_reindex_complete() reopens the searcher from it). An app constructed with a custom index dir resumes into the default directory and the resumed work is invisible in-app. Auto-resume is documented as default-collection-only, but the directory should still follow the app.
  2. Reopening the running modal loses chain context. The busy path pushes IndexerScreen(collection) without chain_total/chain_index, so reopening mid-chain shows a single-run title instead of "(N of M)".
  3. reindex_collection_async proceeds on stale config after a failed reload. The load() is wrapped in suppress(Exception); on failure it rebuilds against the pre-edit source list instead of surfacing the error.
  4. Audit: chain state across cancel-then-restart supersede. A superseded run's teardown deliberately leaves chain state alone (run_seq guard; test_indexer_cancel_race asserts this so an update-all restart keeps its queue). Worth auditing the other interleaving: cancel mid-chain then immediately start a single reindex — start() reads chain_active from the leftover chain_remaining, so the stale queue may continue after the single run. Clearing responsibility currently sits with whoever starts a new chain; decide where it should live and add a test for the single-run-after-cancelled-chain case.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions