fix(server): persist automatic thread settlement

[t3dotgg]

Thread settlement was partly inferred in each client from local clocks and row-level PR state. That let web and mobile disagree, and pinned threads could appear settled for inactivity or a closed PR.

This moves automatic settlement into a server reactor that persists the existing thread settlement event. Pinned threads now ignore inactivity and closed PRs; a merged PR is their only automatic settlement path. Clients render the projected settled timestamp directly, and the inactivity setting is server-owned.

Tested with 203 focused tests plus targeted lint and typechecks across server, contracts, client runtime, web, mobile, and desktop.

Made with GPT-5.6 Sol in T3 Code via the Codex harness.

---

Note

High Risk
Changes core thread lifecycle and cross-client consistency; server reactor plus PR provider lookups can mis-settle or delay settlement if reconciliation or caching behaves badly.

Overview
Automatic thread settlement moves to the server so web, mobile, and desktop all read the same settledAt projection instead of inferring settled state from local clocks, inactivity rules, and per-row PR subscriptions.

A new ThreadSettlementReactor runs on a timer (and on server settings changes), evaluates resolveAutomaticSettlementReason, and dispatches thread.settle for inactivity or merged PRs. PR lookups are cached and rate-limited; failed lookups do not settle (fail closed). Closed PRs no longer auto-settle; pinned threads skip the inactivity timer and only auto-settle on merge.

Clients drop effectiveSettled, onChangeRequestState, and useNowMinute for settlement; list UIs treat a thread as settled when thread.settledAt !== null. The inactivity threshold moves from sidebarAutoSettleAfterDays (client) to threadAutoSettleAfterDays (server settings), edited in beta settings via usePrimarySettings.

^{Reviewed by Cursor Bugbot for commit c2d1810. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Persist automatic thread settlement on the server instead of computing it client-side

• Introduces ThreadSettlementReactor on the server, which periodically evaluates threads and dispatches thread.settle commands based on inactivity or merged PR state, replacing all client-side auto-settlement logic.
• Moves threadAutoSettleAfterDays from client settings (sidebarAutoSettleAfterDays) to server settings, with a default of 3 and a nullable option to disable; clients no longer compute or store this value.
• Web sidebar, mobile sidebar, and home screen now classify threads as settled solely when thread.settledAt is non-null (server-projected), removing all client-side PR state tracking and inactivity calculations.
• Removes effectiveSettled, threadLastActivityAt, and ChangeRequestStateLike from packages/client-runtime/src/state/threadSettled.ts; any remaining callers will fail to build.
• Behavioral Change: closed PRs no longer trigger settlement; only merged PRs do. Pinned threads ignore the inactivity timer and settle only on merge.

^{Macroscope summarized c2d1810.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 680f596b-9b72-4b8e-9c23-a539a2431ea0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 851d0f2. Configure here.}

[macroscopeapp]

Effect service conventions: the new ThreadSettlementReactor service is introduced with a standalone ...Shape interface, split across Services/ and Layers/, and non-canonical make/layer export names. Inline comments describe the expected shape (canonical single module, inline interface, make/layer, Foo["Service"]), which is the pattern used elsewhere in this repo (for example apps/server/src/workspace/WorkspacePaths.ts, apps/server/src/serverSettings.ts). The settlement policy module, its tests, and the mechanical reactor/harness wiring look fine.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Effect service conventions review: the new ThreadSettlementReactor service is introduced in the older split Services/ + Layers/ shape, rather than as one canonical module with an inline service interface and make/layer exports. Two inline comments below; the rest of the diff (pure threadSettlement.ts helpers, contracts/settings changes, client consumers, test/harness Layer.succeed seams) looks consistent with the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Effect service conventions — findings (inline comments could not be attached, posting here):

1. apps/server/src/orchestration/Services/ThreadSettlementReactor.ts + apps/server/src/orchestration/Layers/ThreadSettlementReactor.ts

The new service is split across a Services/ module (tag + standalone ThreadSettlementReactorShape) and a Layers/ module (construction + layer). Consider defining it in one canonical module, apps/server/src/orchestration/ThreadSettlementReactor.ts, ordered imports → Context.Service tag with the interface declared inline → make → layer, and dropping the ...Shape type so consumers refer to ThreadSettlementReactor["Service"]. Callers (Layers/OrchestrationReactor.ts, server.ts, the unit test and integration/OrchestrationEngineHarness.integration.ts) would then import that single path.

2. apps/server/src/orchestration/Layers/ThreadSettlementReactor.ts:49,240-243

This is the single implementation of the service and the module is named for it, so the canonical export names are plain make and layer:

export const layer = Layer.effect(ThreadSettlementReactor, make);

makeThreadSettlementReactor / ThreadSettlementReactorLive naming is reserved for abstract-port modules that hold one of several possible implementations. Likewise, the shape references at lines 219 and 237 should become ThreadSettlementReactor["Service"]["start"] and satisfies ThreadSettlementReactor["Service"] once the interface lives inline in the tag.

No other convention issues found: dependencies are acquired via yield* Foo in make, no ManagedRuntime/runPromise was introduced in service code, the Layer.succeed uses are test/harness seams, Effect.catch handles the whole error channel intentionally, and no new error classes were added.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR introduces a new server-side reactor that actively manages thread settlement, moving logic from client-side computation to server-persisted state. The architectural change introduces new background processing (periodic PR lookups, settlement dispatch) affecting all clients and warrants human review.

No code changes detected at c2d1810. Prior analysis still applies.

^{You can customize Macroscope's approvability policy. Learn more.}