mirror of
https://github.com/stablyai/orca.git
synced 2026-10-01 16:02:03 +00:00
Brennan BensonandClaude
ad6cb0e05c
* fix(worktrees): version every catalog publication so a stale listing cannot undo a create
A worktree listing is a snapshot from when its scan began. The renderer treated any
authoritative listing that lacked a known worktree as proof of deletion, judged at apply
time against the live store, so a listing delayed past a create reply purged the new
workspace: tabs wiped, selection cleared to the landing, pending structured launch
tombstoned so the host session was closed the moment it published. #22311 re-runs a scan a
mutation overtakes, which covers a bump during the scan but not a reply that is simply
applied late, on the host or in the renderer, or a refresh that joined an older one.
The host now stamps every listing with the catalog version its scan began at (the existing
per-repo scan generation, scoped by a per-process epoch) and every create and remove reply
with the version the mutation produced. Clients keep the newest version applied per repo
and host; a listing older than that is not applied at all, not its rows, not its purge, not
the pre-merge terminal teardown. Coalesced joiners inherit the reply and therefore the rule.
Fields are optional on the wire; older hosts and clients keep today's behavior.
* fix(worktrees): relist after a refused stale listing and stop version churn
- A refused listing can be the only answer a caller gets (a change-event
refresh that joined an older in-flight listing), so fetchWorktrees lists
once more; that listing scans at or past the applied version.
- An equal catalog version keeps the held object, so a no-op listing no
longer writes store state on every refresh.
- Versions the client cannot order are treated as unstamped at ingest.
- worktree.rm takes the repo from its id selector instead of resolving the
worktree a second time, which also stamped nothing for an id two hosts share.
- A removal on one of two hosts sharing a worktree id records its version.
* test(worktrees): pin the scan-generation bump right after git worktree add on every create path
A listing is stamped with the generation its scan began at, so a create must
advance it before any post-add work can yield. Pins the local desktop, SSH and
runtime local create paths.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(worktrees): bump the scan generation right after git worktree remove
A listing is stamped with the generation its scan began at. Removals bumped it
only at the end, after watcher release, push-target cleanup and the metadata
purge, so a listing scanned before the git removal and one scanned after it
could carry the same sequence. Applied out of order, the older one restored the
removed row until the removal reply. Bump right after the git removal on the
desktop local, desktop SSH and runtime paths, as creates already do.
The ordering pins now witness the generation at the first step after the git
mutation rather than at the re-list, so moving a bump past any intervening
await fails them.
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(runtime): stop leftover worker-recovery retries from firing into later tests
The legacy worker terminal recovery retry timer re-arms itself and had no
way to end, so a runtime from one aggregator test kept rescanning repo-1
through the shared listing mock during later tests, consuming the listing a
lineage create expected ("Worktree created but not found in listing").
Give the controller a dispose() that cancels pending retries and refuses to
re-arm, and have the runtime test harness dispose every controller it
constructed after each test.
* Revert "fix(runtime): stop leftover worker-recovery retries from firing into later tests"
This reverts commit 5879110163. The leaked
recovery retry timer is a pre-existing test-harness flake that also hits
main; it belongs in its own change, not in the catalog-version fix.
* test(worktrees): pin the relist bound and the teardown gate on fetch-all and paired runtime listings
The relist after a refused stale listing had no test holding it to one retry, and the
pre-merge terminal teardown gate was pinned only on the direct fetchWorktrees path: removing
it from fetchAllWorktrees or from the paired-runtime listing path left every suite green.
* fix(worktrees): keep an SSH reconnect going when its listing is older than an applied create
A direct SSH listing refused because a newer catalog is already applied for
that host reported 'stale', the same result as a moved connection. The
reconnect preparation ends on any 'stale' repo and skips the post-connect
workspace sync and terminal correction, and nothing retries that while the
connection holds. The refused listing now reports the host's answer, since
the store already holds a newer catalog; 'stale' stays for a moved
connection or owner.
* test(worktrees): pin the listing teardown gate on the fetchAllWorktrees startup hydration pass
The hydration pass lists through its own call site, and removing its gate left every suite green.
* fix(worktrees): decide a listing's refusal reason inside the merge, and defer the startup purge behind a newer create
The listing merge now returns 'applied', 'superseded' (a newer catalog is already
applied) or 'not-current' (its connection or repo owner moved), decided against live
state inside the store update. Callers switch on it instead of re-deriving the reason
afterwards, which misreported an owner that went away during an older listing as current.
The one-shot startup purge keeps only ids from scanned rows. A create applied after a
repo's listing but before the purge wrote only the visible rows, so the purge closed the
new workspace's tabs, chat tab included. It now defers when any repo's listing is older
than that repo's applied catalog, like a refused listing, and runs on the next pass.
* test(worktrees): pin the startup purge deferral on a listing refused for a changed repo owner
* test(worktrees): pin a direct-authority fetch reporting an older listing as current
---------
Co-authored-by: Claude <noreply@anthropic.com>