Environment
- gortex v0.60.0+dd3bb30, Windows 11 Pro (10.0.26200)
Observed
With two repos tracked, one of whose directory had been deleted from disk
days earlier:
gortex daemon status → tracked repos: table listed 1 repo
(only the live one).
gortex repos → listed 2 repos, including the deleted one:
fastpanel-api | HEAD (none) | INDEXED (none) | LAST INDEXED 2026-07-10 | stale | C:\...\fastpanel-api (path no longer exists).
Two views of the same daemon disagreeing means neither can be trusted as the
inventory. And the ghost was 8 days old — nothing (status, health, repos, a
log line) ever said "this repo's path no longer exists".
A milder variant of the same identity confusion: the SessionStart status
prints the surviving repo as cwd ... is tracked as repo ` ` (empty repo
name) while gortex repos names it domain-manage. See #309 for where that leads.
Confirmed repro (isolated daemon, v0.60.0)
Immediately after rm -rf repo-b (still tracked): both views keep the
repo with no flag — daemon status lists it with its node counts, repos
shows HEAD (none) ... stale with the dead path. Nothing says the path is
gone. The production observation above (status=1 repo vs repos=2, eight days
later, daemon restarted meanwhile) shows the two views then drift apart —
same root cause: repo-path liveness is never checked.
Expected
- One inventory, or at least two views that agree.
- A tracked repo whose
path fails stat should be flagged loudly in both
views (e.g. MISSING — path deleted; run gortex untrack <path>), and
should count against index_health.
Proposed fix
- Make both commands read the same repo registry snapshot.
- Add a
stat check per repo when rendering either view; render a MISSING
state instead of HEAD (none).
- Optionally auto-quarantine: after N days MISSING, suggest (not perform)
untrack in the status output.
Repro
gortex track C:\tmp\some-repo
# wait for index
rm -rf C:\tmp\some-repo
gortex daemon status # repo absent from table
gortex repos # repo present, HEAD (none), no warning
Environment
Observed
With two repos tracked, one of whose directory had been deleted from disk
days earlier:
gortex daemon status→tracked repos:table listed 1 repo(only the live one).
gortex repos→ listed 2 repos, including the deleted one:fastpanel-api | HEAD (none) | INDEXED (none) | LAST INDEXED 2026-07-10 | stale | C:\...\fastpanel-api(path no longer exists).Two views of the same daemon disagreeing means neither can be trusted as the
inventory. And the ghost was 8 days old — nothing (status, health, repos, a
log line) ever said "this repo's path no longer exists".
A milder variant of the same identity confusion: the SessionStart status
prints the surviving repo as
cwd ... is tracked as repo ` `(empty reponame) while
gortex reposnames itdomain-manage. See #309 for where that leads.Confirmed repro (isolated daemon, v0.60.0)
Immediately after
rm -rf repo-b(still tracked): both views keep therepo with no flag —
daemon statuslists it with its node counts,reposshows
HEAD (none) ... stalewith the dead path. Nothing says the path isgone. The production observation above (status=1 repo vs repos=2, eight days
later, daemon restarted meanwhile) shows the two views then drift apart —
same root cause: repo-path liveness is never checked.
Expected
pathfailsstatshould be flagged loudly in bothviews (e.g.
MISSING — path deleted; run gortex untrack <path>), andshould count against
index_health.Proposed fix
statcheck per repo when rendering either view; render a MISSINGstate instead of
HEAD (none).untrack in the status output.
Repro