Skip to content

A change's review reads the change itself, and rows name their repository when a Mate has two - #52

Merged
fxck merged 4 commits into
mainfrom
fix/change-read
Oct 1, 2026
Merged

fxck merged 4 commits into
mainfrom
fix/change-read

Conversation

@fxck

@fxck fxck commented Oct 1, 2026

Copy link
Copy Markdown
Member

On a Mate with open changes in two repositories, the menu showed two rows both reading "#1", and a change's Review dialog said "Reading this change" forever.

The dialog never asked Gitea. It read the change only once the project's whole flow was loaded. After a reload, groups' flows are read two at a time, and one group's read alone was measured at 74 requests in 97 s. Its spinner also covered idle, where no request had gone out. The dialog now reads the change itself, by the group's slug from the registry. It spins only while a read is in flight, and otherwise says why it can't read (the Gitea sign-in, the project's changes failing, or a project not known here).

Rows name their repository when one Mate's changes span more than one, as "appdev #1 …" and "apidev #1 …", in the menu, the jump box and the project page. The composer strip picks the newest change by its last move and names the repository when needed.

Tests:

  • ZeropsChangeReview.test.tsx renders with empty flows: red on main, green now.
  • A ZeropsReview.logic table checks that only an in-flight read spins.
  • A projectFlow table covers one repo, two repos and a person's change, plus a menu render with two #1s.
  • mateNextStep covers two #1s.

🤖 Generated with Claude Code

fxck added 4 commits October 1, 2026 11:47
Two open changes numbered #1 in appdev and apidev read as the same row in
the menu, the jump box and the project page. Where one opener's changes
span repositories, each row leads with its own: appdev #1, apidev #1.
Numbers are per repository, so two #1s tied; it now picks by when the
change last moved and names the repository where the Mate's changes span
two: waiting for your review of apidev #1.
…w does

After a reload a project's flow waits its turn behind the others', and
the review only read a change on its own once that flow stood, so it
spun on Reading this change with no request sent. It now reads by the
project's Gitea org from the registry whenever the flow does not hold
the change, spins only while that read is in flight, and says why where
no read went out: the Gitea sign-in, the project's changes failing, a
project not known here.
@fxck
fxck merged commit 6082fc5 into main Oct 1, 2026
11 checks passed
fxck added a commit that referenced this pull request Oct 1, 2026
- #50 A person's own new project never waits on the path for someone else's
- #51 A docked operation offers to open only when opening adds something
- #52 A change's review reads the change itself, and rows name their repository when a Mate has two
- #54 A coming-up Mate's page hands over as soon as the Mate answers, whatever the browser kept
- #53 The account's line: Try now shows it tries, names what isn't answering, and one org's trouble holds no other
- #56 The composer's top lists every change that waits for review
- #55 A message echoed in the run card shows its words and its pictures
- #57 One stalled subscription retries alone instead of replacing the organization's socket
- #58 Docs: what the hours after 0.11.74 measured, and the fixes they took
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant