A change's review reads the change itself, and rows name their repository when a Mate has two - #52
Merged
Merged
Conversation
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
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.tsxrenders with empty flows: red on main, green now.ZeropsReview.logictable checks that only an in-flight read spins.projectFlowtable covers one repo, two repos and a person's change, plus a menu render with two #1s.mateNextStepcovers two #1s.🤖 Generated with Claude Code