Repository navigation
feat(server): log how long PR watches stay quiet before they end - #16262
Merged
Merged
Conversation
Loading
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We want to know whether PR watches should end after a quiet period, and we have no data on it. Since #16204 a watched thread stays in Working until its watch ends. Since #16208 a rate limit never ends a watch. A watch on a quiet PR can therefore last until it merges. But nothing records how long watches live or how long they go without a push. The trace file rotates in about 30 minutes on a busy desktop, and the event table is empty on real installs.
A read-only audit of 11 fleet machines (Oct 1 to 5) could answer the other wake questions from saved messages, but not this one.
Now the server writes one local Info log line,
pull request watch ended, for each ended watch. Nothing is sent to analytics.threadId,pullRequestreasonmerged,closed,unreadable,comment-limit,settled,subagent, orstopped(ended outside the reactor: unwatch, Stop, settle, archive, delete)minutesquietMinuteslongestQuietMinuteswakes,readspartialOn boot-service installs, such as the fleet servers, the line goes to
~/.t3/userdata/logs/boot-service.log, which keeps days of history. Desktop installs keep it in the trace file only.Tracking is in memory, so a restart sets it back. A watch that ends while the server is down, or that starts and ends between two passes, is not logged. Wake and end behavior does not change.
Proof: a new runtime test runs a watch through a push 6 hours in, 2 quiet hours, and an unwatch. It captures exactly one log line:
stopped, 480 minutes, 120 quiet, 360 longest, 3 reads, with the thread and PR. The other 12 watch tests pass, and the server typecheck is clean.Reviewed with sol-loop: 3 rounds with GPT-6.1 Sol on high. Declined nits: a host answer with no head SHA counts as a push, which is the same as the watch's own
headMovedrule; and a separate test for each fixed path.Created with Claude Opus 5.5 in Claude Code.
🤖 Generated with Claude Code