Skip to content

[Feature]: Prevent pinned threads from auto-settling #11711

Description

@ImBIOS

Problem

A sidebar pin (pinnedAt) is an explicit keep-active signal, but the server currently auto-settles pinned threads anyway:

  • isAutoSettlementCandidate in apps/server/src/orchestration/ThreadSettlementPolicy.ts never checks pinnedAt, so pinned threads are swept for both inactivity and merged/closed-PR settlement.
  • decider.ts thread.auto-settle has no pinned guard — it even emits a companion thread.unpinned event, silently dropping the user's pin.
  • Docs (docs/user/thread-sidebar.md) state: "Pinning does not prevent automatic settlement."

The existing ThreadSettlementPolicy.test.ts case is even named "blocks pins, ..." but only covers settledOverride: 'active' (the transient keep-active override), not the sidebar pin.

Related:

Proposal

  • isAutoSettlementCandidate returns false when pinnedAt != null (covers inactivity + PR paths, skips PR lookups).
  • thread.auto-settle decider rejects when pinnedAt != null (stale-sweep race: pin landed after the snapshot), while thread.settle (manual) still succeeds and clears the pin.
  • Docs updated: pinning prevents automatic settlement.

Acceptance

  • Inactive pinned thread never auto-settles
  • Merged/closed-PR pinned thread never auto-settles
  • Unpinning re-arms normal auto-settle rules
  • Manual settle of a pinned thread still works and unpins

Activity

  1. juliusmarminge commented on Sep 14, 2026

    @juliusmarminge
    Member

    Triage

    Sidebar pin (pinnedAt) is an explicit keep-active signal, but the server still auto-settles pinned threads (inactivity and merged/closed PR) and thread.auto-settle emits a companion thread.unpinned, dropping the pin. Current docs say pinning does not prevent automatic settlement.

    This is real and matches main. It is an enhancement (documented, intentional today), not a defect.

    Code

    • isAutoSettlementCandidate in apps/server/src/orchestration/ThreadSettlementPolicy.ts never checks pinnedAt, so pinned threads are swept for both inactivity and PR settlement. The reactor filters on that helper before PR lookups.
    • decider.ts thread.auto-settle guards settledOverride only. The shared settle path always unpins.
    • The policy test named “blocks pins, …” only covers settledOverride: 'active' (transient keep-active), not sidebar pinnedAt.
    • Web/mobile already bucket settledOverride === "settled" before pin. If the server never auto-settles a pinned thread, it stays in Pinned with no client change. Manual settle still unpins and lands in Settled.

    settledOverride: 'active' and sidebar pinnedAt are different primitives. Activity clears the former; the latter is durable until unpin or settle.

    Related

    Next step

    Review/merge #11712. Policy + decider + reactor tests and docs match the acceptance list. Unpinning re-arms auto-settle by clearing pinnedAt (no extra work). Pinning a settled thread already un-settles it, so treating pin as keep-active is consistent with pin-as-promotion.

    Not a duplicate of #5575. No second implementation PR needed.

  2. added
    enhancementRequested improvement or new capability.
    acceptedfeature request accepted
    via-triageFiled through npx t3 triage
    on Sep 14, 2026
  3. added a commit that references this issue on Sep 14, 2026
    e53aec3
  4. added 2 commits that reference this issue on Sep 17, 2026
    b13d65a
    2b4bd58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedenhancementRequested improvement or new capability.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions