Repository navigation
Home: read every page of the Cloud inbox (Mac, daemon, classic iOS) - #27752
Conversation
cloud-inbox-list with no limit reads every inbox.list page through next_cursor; with a limit or cursor it reads one page and returns next_cursor. WireHomeSource (classic iOS) follows next_cursor too. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner pages inbox.list by 200 (keyset, next_cursor). The daemon's cloud-inbox-list, home-inbox's Cloud rows, the Mac's CloudHomeSource and classic iOS's WireHomeSource read only the first page, so a Chief or conversation past the newest 200 never showed in Home, and the Mac dropped one it knew from the list on every refresh. - cloud-inbox-list: optional cursor; returns next_cursor. With neither limit nor cursor it follows next_cursor for every page (at most 50 of 200), keeps an entry listed twice once, and answers the first page's revision. home-inbox's Cloud rows use it. - CloudHomeSource asks for the whole inbox (no limit); an older daemon answers its newest 200 as before. - WireHomeSource follows next_cursor (at most 50 pages). - Spec, SDK schema, generated bindings and the api-compat surface name the cursor field. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Review of #27752: a whole-inbox cloud-inbox-list could run 50 reads under the app's one 30 s request timeout and hold a cloud request slot after the app gave up. - cloud-inbox-list is one page per call again (limit default 200), now with cursor in and the owner's next_cursor out. - CloudHomeSource pages itself: up to 50 one-page calls, first copy of an entry listed twice, the first page's revision (touched events after it win). An older daemon's one page is the list. - home-inbox's Cloud rows read every page in the daemon within a 10 s budget after the first page; a later page's failure keeps the pages read. - The integration FakeCloud pages inbox.list as UserDO does; a 450-entry inbox lists every row once through home-inbox. - Spec, SDK constraint text, surface order; bindings regenerated. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…wn; add the live many-Chiefs rig journey configure() starts a background inbox read on the source's daemon, which also logged cursors. The pages now come from a second fake. verify/home_chiefs_paging_live.py: N Chiefs made on the rig Mac; the phone's Home scrolled end to end lists each once, in order, and M more made while it sits at the end show without a touch. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Correctness review (subagent), on 78e1e26, and how each finding was resolved:
Verdict after the fixes: no open correctness findings. |
|
cmux status (one comment, edited in place; each line is updated by the job that owns it) Review App of this head (app.zip, kept 1 day)
web and size checks: green |
…ext-home-chiefs-pagination
|
Found 6 test failures on Blacksmith runners: Failures
|
…eview) Final-head review of #27752: the Mac's HomeInboxSource asked home-inbox with the connection's 2 s default, while the daemon's whole-inbox read could hold a cloud request slot for about 30 s, so a large inbox failed on the Mac and abandoned reads piled up toward the 16-slot limit. - HomeInboxSource asks for Cloud rows with the Cloud's 30 s request timeout (CloudConversationClient.networkTimeout). - The daemon's budget counts from the start of the read and is 8 s, so with one more page's 20 s read it ends inside 30 s. - CloudHomeSource.allPages and WireHomeSource keep the pages already read when a later page fails, as the daemon does. - Doc comments back on their consts; spec wording matches the budget. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…sic iOS (review) Re-review of 846cb0c: keeping a partial list replaced the whole inbox with it, so conversations past the failed page left Home until the next good read. Both readers throw again and the store keeps its last whole list. The daemon's home-inbox keeps its partial pages (its caller takes the rows as one reply, and the first page's failure still fails it). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…navailable A partial list in home-inbox would drop the rows past the failed page on the Mac; failing the read makes the rows unavailable, and HomeInboxSource keeps its last rows then. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Review (claude-opus-5.5 review subagent): SHIP at a68ad03 b19ce52..a68ad03 adds one more merge of feat-cmux-next and no change to this PR's files. That merge brings 7365192 (#28316, "count the participant tag #27935 added (base red)"), which fixes the |
…ext-home-chiefs-pagination
…ext-home-chiefs-pagination
|
Review (claude-opus-5.5 review subagent): SHIP at cf10d6a 5ec7c0a..cf10d6a adds one merge of feat-cmux-next. It brings 84770f4 (#28426), the base fix for tooling-tests that next-autoland was waiting for ("base red since fixed"). The merge auto-merged WireHomeSourceTests.swift, where the base added attachment tests; cmux-ci 0f2fa30c4128 shows WireHomeSourceTests passing at this head. release-notary is still red on the base tip (4db9c7d, test_digest.py and the signing-hooks test). |
…ext-home-chiefs-pagination
|
Shipped in:
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light-3x.png)
Summary
A user reported that Home doesn't paginate its Chiefs properly. Findings:
inbox.listpages by 200 with a keysetnext_cursor. The daemon'scloud-inbox-list(which had no cursor field),home-inbox's Cloud rows, the Mac'sCloudHomeSourceand classic iOS'sWireHomeSourceall took page 1 and stopped. A Cloud Chief or conversation past the newest 200 never showed in Home.home-inboxlist in one reply (MacHomeFeed), so it has no paging to get wrong. In a live run with 25 Chiefs it listed each one once and in order, and 5 Chiefs made while Home sat at the end showed up in 0.5 s.MAX_SERVER_CONNECTIONS), and each Chief's host holds more. With 60 Chiefs the phone'schiefchannel was refused ("Couldn't read this Mac's Home: daemon channel closed"), and so wascmux chief new. This needs a separate daemon-side change.Fix
cloud-inbox-list {limit?, include_archived?, cursor?}reads one page per call and returns the owner'snext_cursor, so every reply is one bounded read.CloudHomeSourcepages with the cursor (at most 50 pages). An entry listed twice keeps its first copy, and the first page's revision is used, sotouchedevents after it still win. An older daemon's single page is still the list.home-inbox's Cloud rows read every page in the daemon, within 10 s after the first page. If a later page fails, the pages already read are kept.WireHomeSource(classic iOS) followsnext_cursorthe same way.sdk-schema.json, the regenerated bindings andapi-compat.surface.jsonincludecursor.cmux-next-ios/verify/home_chiefs_paging_live.py: N Chiefs, scroll Home end to end, then M more made live.Changelog
Testing
Red/green results (focused commands):
cargo test --locked -p cmux-tui --test ws_cloud_conversations home_inbox(rbx): on base 0da5bc3 plus the new test, it fails with 200 rows instead of 450. On 4039a59 it passes (3/3).cargo test --locked -p cmux-tui-core --lib inbox_list(rbx): the first version's tests were 3/3 red on the base and green on the fix. The final tests are 4/4 green on 4039a59.package-test-lane.sh suite Packages/Shared/CmuxHomeCore WireHomeSourceTests(cmux-ci):theInboxReadsEveryPagefails on 32b928c (only the first page, cursors[nil]) and passes on 78e1e26.package-test-lane.sh suite Packages/macOS/CmuxNext CloudInboxPagingTests,CloudPinMuteTests,CloudAttachmentTests(cmux-ci step 3282f12652eb): passes at scratch 262168f, which is this head plus fix(cmux-next): await FolderChanges.events() in the machine consent watch (base Release compile red) #27722.Observed / Not run
homepg, cmux-next iOS Demo build, simulator iOS 26.5).artifacts/home-chiefs-pagination/report.htmlin cmuxterm-hq.JoinConsent+App.swift:222, fixed by fix(cmux-next): await FolderChanges.events() in the machine consent watch (base Release compile red) #27722 and cmux NEXT: await FolderChanges.events() in MachineConsentChanges (build fix) #27758), so they ran at scratch SHAs with fix(cmux-next): await FolderChanges.events() in the machine consent watch (base Release compile red) #27722 cherry-picked.No capture: the fix is a data read past 200 Cloud inbox entries, and no Home layout changes. The live phone stills are in the report.
🤖 Generated with Claude Code