A lane control root that cannot be searched reads as "no trees", so an inventory sync removes its rows (from #289's review)

Found by the independent review of PR #289 (#173 item c1), as its SHOULD-4. It is in the same family as #173's original finding: a read that failed is taken as an empty one (R22, Amendment 7(d)). It already exists before #289, at main 21e0829; the line numbers below are at #289's head 03b6299.

A lane's control root that cannot be searched reads as "no trees"

lanes-edit.sh:14518, [ -d "$wr_root/trees" ] || continue, treats EACCES as absent.
So does rung 2's [ -d "$lcr_par" ] at :13128.
Probe P5: with the dir's parent .lane-state at mode 000, the helper exits 8, and an inventory sync writes 0 upserted, 1 removed. That lane's indexed rows are deleted.
Unlike A lane listing that is not whole no longer removes indexed worktree rows: the inventory read says PARTIAL, lanes --worktrees prints it NOT WHOLE, and lanes-index writes nothing over it; an older helper's tree with no path stays a tree (#173 item c1, #252 delta review 2) #289's SHOULD-1 windows, this failure persists. The same happens at 21e0829.

Fix

Walk up to the deepest ancestor that exists. If it cannot be searched, emit UNREAD for the lane, as main's f18b818 did for leg directories, so that the sync holds the lane's rows instead of deleting them.

Lane: openRepoTools-4

CLAIMED — lane openRepoTools-4, session e545e636-93fd-4b80-81b1-48177346b887@Eagle, 2026-10-21T10:34:12Z, for #291

Logged in lanes/log/openRepoTools-4.md at ce0f4790664b8953e26fb751a323813b8ff3514a.

The three reads (lane-collision-protocol Rule 1):

1. existing `CLAIMED —` comments on opensoft/openRepoTools#291:
   none
2. `gh pr list --repo opensoft/openRepoTools --state all --search "#291"`, kept where the row or its body names `#291`:
289	A lane listing that is not whole no longer removes indexed worktree rows: the inventory read says PARTIAL, lanes --worktrees prints it NOT WHOLE, and lanes-index writes nothing over it; an older helper's tree with no path stays a tree (#173 item c1, #252 delta review 2)	fix/lanes-index-partial-listing-173	OPEN
3. `git ls-remote --heads git@github.com:opensoft/openRepoTools` branches naming `291` as a whole token:
   none

A lane whose inventory could not be read is no longer said to have on…

Test that a write under a lane control root nobody could look for fai…

lane_generation's docstring no longer says that a snapshot it could n…

The README's rung section says that a rung is passed over only where …

lane-reconcile no longer says that a trees directory nobody could loo…

The lanes-index marker comment, the second exit-10 header in lanes-ed…

Only the #291 cases that set a mode skip as root, so the links that c…

lookup_blocked's comment names its limit: a denial that the mode bits…

The README's rung paragraph now names what each surface says where a …

lanes-edit.sh worktrees names a lane UNREAD beside a tree record that…

A lifecycle snapshot nobody could look for is 10 to set-lane-state an…

Merge slice 1b at 59551dd into slice 2a: four blocks resolved as unio…

Pin #309's rename-note count, dangling-link control root, fence wordi…

Merge pull request #5 from opensoft/fix/control-root-unsearchable-291

Merge pull request #8 from opensoft/fix/control-root-unsearchable-291

Lane openRepoTools-4, 2026-11-08T13:52Z: closed by hand, as T017's C3 has it, now that both PRs of its pair have landed.

T017: A lane control root that cannot be searched is read as not read, not as no trees: lane-state and lane-trees exit 10, the listing says UNREAD, and a sync keeps the lane's rows (opensoft/openRepoTools#291) (part of opensoft/openRepoTools#186) openRepoTools-code#5 landed by merge commit 70632d32 on the code leg's main at 13:46:17Z, on Brett Heap's typed word "yes, land T017 once code#3 is green" (13:16:08Z, lane openRepoTools-4's session).
- Its parents are c23f5350 (the old main) and ca9b847f (the PR's head).
- Its tree equals the head's, which the four required checks tested green.
T017: A lane control root that cannot be searched is read as not read, not as no trees: lane-state and lane-trees exit 10, the listing says UNREAD, and a sync keeps the lane's rows (opensoft/openRepoTools#291) (part of opensoft/openRepoTools#186) openRepoTools-spec#8 landed by merge commit a33a27ec on the spec leg's main at 13:47:35Z.
- Its parents are b0edc72c and 0b6f2a0b.
- Its tree equals git merge-tree's of the old main and the head: the PR's change, beside spec#6's three files, which the head predates.
It ships in v1.2.0, as Brett let T017 ride ("let T017 ride in 1.2.0, retitle Re-land #341 (openBenches handoff environment) in v1.2.1, with its review's fixes #343", 13:05:37Z).
The landing record is on Releases: annotated tags, release/vX.Y branches, and openrepotools on TestPyPI and PyPI from v1.1.0 #228, with each Rule 6 line in the register.

Lane: openRepoTools-4

RELEASED — lane openRepoTools-4, session e545e636-93fd-4b80-81b1-48177346b887@Eagle, 2026-11-08T13:54:04Z, for #291 — landed in T017 on Brett's word: code#5 by merge commit 70632d32 and spec#8 by a33a27ec; the issue is closed by hand

Bump the code leg from 2a057a6 to e393958, which carries the openRepo…

Navigation Menu

Repository navigation

A lane control root that cannot be searched reads as "no trees", so an inventory sync removes its rows (from #289's review) #291

A lane's control root that cannot be searched reads as "no trees"

Fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

A lane control root that cannot be searched reads as "no trees", so an inventory sync removes its rows (from #289's review) #291

Description

A lane's control root that cannot be searched reads as "no trees"

Fix

Activity

brettheap commented on Oct 21, 2026

brettheap commented on Nov 8, 2026

brettheap commented on Nov 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions