Uh oh!
There was an error while loading. Please reload this page.
fix: keep auto-settle policy consistent across clients - #5290
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
ApprovabilityVerdict: Needs human review This PR moves thread auto-settlement policy from client-side settings to server-side environment configuration - a cross-cutting architectural change affecting mobile, web, and server. The author labeled it 'Medium Risk' as it changes how threads appear across connected clients. You can customize Macroscope's approvability policy. Learn more. |
cb360a6 to
08b6d70Comparet3dotgg
commented
Sep 1, 2026
Note 🤖 GPT-5.6 Sol responding on behalf of Theo We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together. Merged PR #8600 moved automatic settlement to the server, with one policy per environment and saved settlement state across clients. This replaces the client-derived classification proposed here. Policy changes do not reopen settled threads. The server change is in v0.0.38. If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed. |
What Changed
thread.settle, and the server does not schedule settlement eventsWhy
Web/desktop read
sidebarAutoSettleAfterDaysfrom local client persistence, while mobile hard-coded the default of three days. A desktop configured for seven days and a mobile client connected to the same server could therefore put the same thread in different shelves.The existing server-settings RPC is already remotely writable and streamed to connected clients, so the policy now lives there. Explicit settle/un-settle remains the durable server lifecycle; crossing the inactivity threshold only changes the derived list classification. This avoids clients racing automatic settle commands and lets a policy change reclassify threads immediately.
The default remains three days. The legacy client field and exported names remain decodable for downgrade/source compatibility, but local values no longer drive upgraded clients; automatically importing whichever client connects first would recreate the same ownership race. In multi-environment lists, each backend owns its own policy rather than one client silently mirroring writes to other environments.
This establishes the ownership boundary that overlaps with #5141. Its proposed additional auto-settle controls should extend the server-owned policy rather than introducing separate web and mobile preferences.
UI Changes
No layout or interaction changes. The existing General setting now updates the primary environment and is read-only against older servers that do not advertise policy updates, so screenshots/video are not applicable.
Verification
vp test run packages/contracts/src/settings.test.ts apps/server/src/serverSettings.test.ts packages/client-runtime/src/state/threadSettled.test.ts apps/mobile/src/features/threads/threadListV2.test.ts— 269 passedgit diff --checkChecklist
Model: GPT-5.6-Sol | Harness: Codex in T3 Code
Note
Medium Risk
Changes how threads appear in sidebars across clients and introduces server-streamed policy with version-skew gating; behavior can shift when local client thresholds differed from the environment default.
Overview
Moves inactive thread auto-settle from per-device client settings (
sidebarAutoSettleAfterDays) to per-environment server settings (threadSettlement.autoSettleAfterDays), streamed to connected clients so web, desktop, and mobile classify the same threads the same way.Contracts & server: Adds
ThreadSettlementSettingsonServerSettings, renames the day-threshold constants toTHREAD_AUTO_SETTLE_*, keeps the old client field only for downgrade decoding, and advertises a newthreadSettlementPolicycapability. The server persists policy patches and tests cover enable/disable.Clients: Web sidebar, chat view, thread actions, and General settings now read/write the primary environment’s streamed policy (controls disabled when the server lacks
threadSettlementPolicy). Mobile thread list v2 takes a per-environment map instead of a single hard-coded default; classification still treats inactivity as a derived settled view, not a server settle command.Docs: New user doc on thread settlement and a README link.
Reviewed by Cursor Bugbot for commit 08b6d70. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Move auto-settle policy from client preferences to per-environment server settings
threadSettlementsection to server settings with anautoSettleAfterDaysfield (default: 3 days, nullable to disable) and athreadSettlementPolicycapability flag so clients can detect support.buildThreadListV2Itemsto accept a per-environment map (autoSettleAfterDaysByEnvironment) instead of a single global value; threads fall back toDEFAULT_THREAD_AUTO_SETTLE_AFTER_DAYSwhen no policy is set for their environment.serverConfig.settings.threadSettlementrather than a local client preference.threadSettlementPolicysupport.sidebarAutoSettleAfterDaysin client settings is deprecated but retained for downgrade compatibility; existing clients on servers without the capability will use the fixed 3-day default.Macroscope summarized 08b6d70.