v1.2.4: ready view starves reconcile/periodic verification while the only work slot is reserved under storage pressure

Start by comparing the scheduler’s collection state with the maintenance aggregate during storage pressure, then trace how the only work slot is reserved while recovery and collection make no progress. Use the retained status snapshots and runtime logs to reproduce the stalled state; done means a few invalidated paths reconcile, periodic verification runs, and unproductive maintenance releases the slot while scheduler and maintenance state agree.

Summary

On tgrep v1.2.4 (official signed Windows x64 build), a ready shared managed view on a large repository goes ready:false after a handful of watcher invalidations and never reconciles. No reconcile work is scheduled for more than 5 minutes while the namespace's only work slot stays reserved and a collection sits accepted/queued under storage pressure. The scheduler reports successful ticks throughout.

This is the same symptom class as the v1.2.3 stall described in #210. v1.2.4 greatly reduced the input churn (8 epoch advances instead of about 2,000), but the starvation remains.

Environment

• Repository: 293,288 tracked files (a large private monorepo), linked worktrees on a ReFS Dev Drive, Windows 11 x64.
• The Copilot runtime starts tgrep with built-in default policy: workers: 1, work_slots: 1, storage budget 16 GiB, interval_ms: 120000, native watch mode.
• Three native views (seed plus two linked worktrees) share one daemon.

Timeline (run v124d)

1. Cold readiness took 20.3 min, down from 25–32 min on 1.2.3.
2. Two peer worktrees became ready after 11.9 and 20.6 min. A pooled session became ready after 2.2 s. One daemon served three runtimes.
3. A native periodic-verification receipt was observed.
4. Three indexed queries (lit-ultra-rare, lit-rare, lit-uncommon) matched ripgrep exactly, including their parity variants.
5. Before the next query, the seed view stayed ready:false for the whole 300 s readiness budget (119 status observations).

State while stalled (seed view)

• serving: true, ready: false, work: null, error: null, queries: 0, leases: 1.
• input_epoch: 8, reconciled_epoch: 1.
• watch_events: 303 events (modify 299, create 4), epoch_advances: 8, invalidated_paths: 8, unchanged_paths_filtered: 252, full_invalidations: 0.
• last_verification: unchanged, age_ms rising from 358,195 to 655,065 against a 120,000 ms interval. Periodic verification is therefore also starved.
• last_reconcile: epoch 1 full, queue_us 119.8 s, admitted_us 281 s.

Namespace and scheduler

• Scheduler:
  • collection_in_flight: true, collection_operation_state: "accepted", collection_queued: true.
  • pressure: true, recovery_continuation: true.
  • failed_ticks: 0, last_successful_tick_elapsed_ms current.
• Maintenance aggregate: collection.in_flight: 0; 8 collections completed, reclaiming 0 bytes; 343 recovery passes completed, reclaiming 0 bytes.
• Usage:
  • reserved_slots: 1 of 1.
  • reserved_staging_bytes: 8589934592 (100%), reserved_private_bytes: 7191533823.
  • charged_budget_shortfall_bytes: 5353358930, 7 checkpoints.

Only 8 paths need reconciling, which should take seconds. However, the single work slot is held, and storage pressure keeps collection and recovery cycling without reclaiming anything. The scheduler also reports a collection in flight that maintenance does not.

Expected

• Incremental reconciliation of a ready view, and its periodic verification, can run while collection or recovery is pending, or preempt them.
• Unproductive collection or recovery (0 bytes reclaimed) does not keep the only work slot reserved.
• The scheduler's collection state agrees with maintenance.
• Per the 1.2.4 notes, a ready view reconciling a few invalidated paths should report lagging / stale_reads and keep ready, rather than drop to ready:false with no work scheduled.

Impact

The Copilot runtime only routes searches to indexed views that are ready, so results stay correct (it falls back to a filesystem scan). Indexing is lost until the view reconciles, which did not happen within 5 minutes.

Evidence (status snapshots with first-unready and last status, runtime logs) is retained and can be shared on request.