Snooze a thread until its pull request changes

[Zheckan]

Summary

Add Until pull request changes to the snooze menu. The thread stays snoozed until its linked pull request gets a review, a comment, a check result, or a merge conflict. Then it comes back to the sidebar with a note that says what changed. The agent does not run.

Problem

I contribute to open-source projects where a review can take a week or a month. I open a pull request from a thread, and then the thread waits. After three idle days, auto-settle moves it to the settled shelf. When a reviewer finally comments, nothing in T3 Code tells me. I hear about it from GitHub, then search the settled shelf for the thread where I wrote the change, so I can make the fix with the same context.

Snoozing for a fixed time doesn't help much. I have to guess when the reviewer will get to it. If I guess short, the thread comes back with nothing new and I snooze it again. If I guess long, the review sits unseen until the snooze ends.

Proposal

The option appears for threads that have a linked open pull request.

1. The thread moves to Snoozed, like any other snooze.
2. The server checks the pull request on the same schedule as watch_pull_request and reuses its reads.
3. When something changes, the server wakes the thread and adds a timeline notification that says what changed. The agent does not start a turn.

A change is anything the watch already reports: a check fails, the required checks pass, someone other than me comments or reviews, or the branch starts to conflict. My own pushes and comments don't count.

This is a snooze and not a settle on purpose. Settled means the work is done, and settling a thread ends its pull request watches. A snoozed thread also doesn't auto-settle while it waits.

Wake thread works as it does today and also stops the check. The option works on web, desktop, and mobile, and on every host that watch_pull_request supports.

Why watch_pull_request doesn't fit

The closest option today is to ask the agent to call watch_pull_request, then snooze the thread for a long time. When the watch sees a change, it starts an agent turn, and the thread comes back after that run completes.

That hands the review to the agent. It reads the comments and starts acting on them before I have seen them. I want to read the review myself first, decide what to change, and then tell the agent what to do. Each check result and comment also costs an agent turn, and the watch stops after 10 comment-only wakes in a row.

Related

• Auto-snooze green PRs from the PR watch tool, opt-in setting #15303 snoozes a thread automatically once its watched pull request goes green. This proposal wakes a thread I snoozed myself when its pull request changes.
• Snooze a running thread until its run ends #14819 asks for a snooze that ends when a running thread's run ends. It also wakes on an event instead of a time, but on a different event.

[ashx-j]

This would be useful to me. Could it also cover replies on merged PRs and GitHub discussions?

For example, I just used an agent in T3 to comment on a merged PR with a feature suggestion. I'd like to snooze that T3 thread until someone responds, then have it return to my inbox with the new comment and a link. The agent wouldn't need to run or reply automatically.

The same applies when an agent posts in a GitHub discussion. Once we've sent the message, there's nothing for me to do until someone responds, and a fixed snooze time means guessing when that will happen.

An option like “Snooze until someone responds” would fit this well. Would that fit the scope of this proposal, or should it be a separate discussion?

---

Sent by gpt-6-astra, responding on behalf of ashx-j.

[Derpedyea]

+1. My case is narrower: a snoozed thread should come back when a reviewer requests changes. Approvals and drive-by comments can wait for the snooze to end.

I read through main (04ad174) to see how close this already is:

• A watched thread already unsnoozes. A watch_pull_request wake is sent as a message (Orchestrator.ts#L2324), and sending a message clears the snooze (#L4563). So snoozing for a week while the agent watches the PR mostly works today. It falls short in three ways:
  1. Only an agent can start a watch. The thread's PR row can stop one but not start it (ThreadDetailsPrRows.tsx).
  2. Every wake starts an agent turn. When a review takes days, I want to see it first, not have the agent reply.
  3. Any outside comment, check result, or conflict wakes it, and the watch ends after 10 comment-only wakes in a row (pullRequestWatch.ts#L13).
• The watch already sees "changes requested". A review with no body is still read when its state is a verdict (gitHubPullRequestJson.ts), so filtering on it needs no new host reads. GitLab has no such state (GitLabPullRequestProvider.ts#L47), so that filter can't apply there.
• A snooze needs a future wake time (Orchestrator.ts#L2705). Keeping a fallback ("until the PR changes, or in 2 weeks") avoids an open-ended snooze.

Decisions for maintainers:

1. On wake: notify only (this proposal) or start the agent (today's watch)?
2. Which events count: all, reviews only, or changes requested only?
3. Required fallback time, or open-ended?

[benthecarman]

this would be great, otherwise i find the sidebar unusable

[ekrako]

An alternative that changes less: keep the current snooze times and treat them as check intervals. When the wake time comes, look at whether the pull request changed since the thread was snoozed. If it didn't, snooze it again for the same length. If it did, wake it as usual.

So "Tomorrow" means "check tomorrow, and come back only if the PR moved." Only the wake condition changes. There's no watch, no agent turn and no new host reads. The fallback-time question also goes away, because the snooze length already caps how long a change can go unseen.

The option is disabled when the thread has no linked open pull request, since there's nothing to check. If the PR merges or closes while the thread is snoozed, it counts as a change and the thread wakes.

The PR sync that keeps the thread's pull request rows current already has what this needs:

• PullRequestSyncReactor reads every unsettled thread's open PR links once a minute (PullRequestSyncReactor.ts#L479). A snoozed thread counts as unsettled, so it's already included.
• Each link keeps a snapshot with the host's updatedAt, reviewDecision, checksState and mergeability (#L52). The snapshot is only rewritten when one of those fields changes (#L225), so snapshot.syncedAt > snoozedAt already means "the PR moved since I snoozed." That includes check and review-state changes, not just comments.
• The thread stores snoozedAt and snoozedUntil, so the original length is snoozedUntil - snoozedAt.

The check would run in that sweep. For a thread snoozed with this option whose wake time falls before the next sweep, if no linked PR synced after snoozedAt, dispatch thread.snooze again with now + (snoozedUntil - snoozedAt). It has to run one sweep early because there's no server event at wake time; clients just compare snoozedUntil with the clock. Re-snoozing after the time passes would make the thread flash into the sidebar for up to a minute.

Tradeoff: my own pushes and comments also move the snapshot, so they would count as activity. In practice those happen while I'm working in the thread, before I snooze it, so I don't think this matters much.