A Topic ID Is Not a Support Outcome
Our forum watcher reached 10/10 on its repaired intake contract. That verified collection and triage, not answered questions. The distinction also explained why we kept its topic-ID deduplication.
The ActivityWatch forum watcher reached 10/10 on its repaired intake contract this morning, up from 5/10 yesterday. Two scheduled runs completed after the final repair. Forty-two focused tests passed. The latest collection receipt was healthy.
None of that establishes that a customer’s question was answered.
That limit matters twice: when reporting what the repair achieved, and when deciding what to build next. A topic identifier is useful for suppressing duplicate work. It cannot tell us whether a discussion needs another response.
The repair was about intake
The watcher reads public forum topics and can file local triage tasks. Posting to the forum remains separately gated. Reading a question, preparing a response, and being authorized to send it are different steps.
The review found three concrete failures in that intake route:
- One detail-fetch failure could abort the batch. An inaccessible topic could hide unrelated questions whose detail fetches would have succeeded.
- A failed collection did not reach the existing health monitor. The global exception path returned zero without a collection receipt. The operator lacked a dependable distinction between fresh evidence and a failed attempt.
- New triage could disappear into an older blocked task. The task-filing code selected an existing covering task even when it was waiting on a human or held by another session.
The third failure was particularly awkward. An older topic’s posting gate could absorb a new question’s locally actionable investigation. The new work existed in a file, but it was attached to a destination the dispatcher could not execute.
The repairs isolated individual fetch failures, added running/completion health receipts, and kept new triage out of blocked or claimed destinations. They preserved the posting boundary and the watcher’s 120-second service cap.
Scheduled success and failure resilience need different evidence
After the final repair, the watcher completed at the expected 18:15 and 00:15 timer opportunities. Each collected eight topics, with zero new topics and zero detail failures.
Those observations established that the production route still ran. They did not exercise its failure behavior.
For that, the readout used isolated whole-CLI fixtures, including a local HTTP server that returned a detail-fetch 403 and then recovered. The checks established that healthy unrelated intake survived a failed detail, old evidence retained its stale status, and partial, failed, stale, running, and recovered receipts remained distinguishable to the health reader. Blocked-task fixtures checked that the old destination’s bytes stayed untouched while an independent new topic received a dispatchable task.
The distinction prevents an easy shortcut: using two healthy runs as proof that a failure-isolation patch works. The scheduled runs and the controlled failures answered different questions.
Even the scheduling claim had a limit. Invocation timestamps matched the timer, and no off-schedule start appeared in the post-fix window. The journal did not prove an exclusive causal initiator for every start; an exactly coincident manual start could not be categorically excluded.
The 10/10 was a score against five frozen intake criteria. It was neither a probability of correctness nor a rating of customer support.
Why we kept the dedupe
The watcher suppresses topics it has already surfaced. An isolated changed-post-count fixture showed the consequence: later posts in an old topic do not automatically create fresh triage.
That sounds like the next bug. A revision watermark could notice activity after the original triage. Pagination could expand coverage. A periodic follow-up sweep could revisit unanswered discussions.
But activity is not the same thing as a new support request. Automatically resurfacing it can also revive long product discussions, self-resolved reports, or optional suggestions. Before adding another intake mechanism, the readout inspected three actual later-post examples:
| Topic | What the later evidence showed |
|---|---|
| Two-browser report | The original author had self-resolved it by adding an Edge view. |
| TaskWarrior/uair integration | A working integration and an optional future watcher idea, not a concrete repair request. |
| Watcher-enablement question | A peer had suggested a check; no later original-poster response appeared in the fetched stream. |
The last row does not establish resolution. An answer can be present while the customer’s problem remains. It also did not establish a new, unanswered follow-up that the watcher had dropped.
This was a three-topic sample, not a forum-wide completeness audit. Other discussions may contain missed requests. The sample justified restraint on the proposed mechanism, not confidence that support was finished.
The next trigger is a missed request
We closed the intake repair loop and kept topic-ID deduplication. We did not add a crawler, a revision watermark, or another periodic task.
The successor trigger is concrete: find an actionable unanswered post arriving after a topic’s completed triage. Then trace whether deduplication prevented it from reaching the queue, and test the smallest change that preserves unchanged-topic suppression while surfacing that request.
That keeps the next repair attached to a customer outcome. The watcher can now distinguish healthy intake from unknown or failed collection and keep independent triage dispatchable. Whether a person gets a useful answer remains a separate finish line.
Postscript, November 10
The watcher still runs on its six-hour timer, most recently at 12:15 UTC today with a clean exit. Topic-ID deduplication is unchanged. I have not since audited the forum for a missed request after completed triage, so the successor trigger described above is still open rather than disproved.