Report a briefless thread as absent and stop backfilling dormant ones - #2
Merged
Merged
Conversation
The sweep enqueued every briefless thread on every pass, with nothing to stop it: the first time a key is configured that is an unbounded burst across every thread in the list, and a thread whose summary keeps failing is retried every ten minutes forever. Bound it. A briefless thread is given its first brief only if it was active inside a 24h window; anything dormant longer stays briefless. Briefs are not backfilled, which is the intended behaviour, so the UI has to say so. `getBrief` therefore distinguishes work that is genuinely pending — debounced, queued, or in flight — from a thread that has no brief and is not getting one. The first is `summarizing`, the second is the new `absent`, which the popover renders as "No brief for this thread yet" plus a Summarize now button rather than a spinner that would never resolve. A failed summary drops back to absent and announces, so the UI stops claiming a summary is on its way. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The 24h backfill window was an arbitrary cutoff that still summarized every briefless thread touched in the last day — a burst on first configure, just a smaller one. The rule wanted is simpler: a thread earns its first brief through activity. So the sweep never creates a first brief for a thread whose last activity predates this plugin load. Past that point its only job for a briefless thread is activity whose `thread.idle` we should have seen and missed. A thread dormant since before we started stays briefless at no cost, however old, and gets a brief the moment it is worked on again. Drops BACKFILL_WINDOW_MS; the cutoff is the load time we already know. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #1, answering "do we avoid generating briefs when a thread has been inactive?" — mostly yes, with one real gap.
Safe already: an inactive thread that has a brief is never re-summarized (no
thread.idlefires, and the sweep'slastSummarizedAt < updatedAtis false), and an active thread mid-burst is held by the debounce.The gap: a thread with no brief passed the sweep's gate unconditionally, so it was re-enqueued on every pass forever. That means an unbounded burst across every thread in the list the first time a key is configured, and an endless ten-minute retry for any thread whose summary keeps failing.
What changed
Bound the backfill. A briefless thread gets its first brief only if it was active inside a 24h window (
BACKFILL_WINDOW_MS). Anything dormant longer stays briefless.Make the UI honest about that. Briefs not being backfilled is the intended behaviour, so the UI has to handle it — previously
getBriefreturnedsummarizingfor any briefless thread, meaning an old thread would show "Summarizing…" forever. Now:summarizingonly when work is genuinely debounced, queued, or in flight;absentotherwise, rendered as "No brief for this thread yet" plus a Summarize now button;absentand announces, so the UI stops claiming a summary is coming.Tests
65 passing (was 59). New cases: absent vs summarizing, no backfill past the window, backfill inside it, quiet-period threads left alone, and the popover offering to summarize instead of spinning.
One of them corrected a wrong assumption of mine — a fresh thread is not backfilled either, because the sweep's quiet-period gate skips it until it has been idle for
quietSeconds. The backfill window and the quiet period are two separate bounds.🤖 Generated with Claude Code