Problem (v13 observability)
#12810 added the mini-summary backlog count to the orchestrator log: the memory-summary-backfill task only fires when there's a backlog, so it always logs pending-memory-minisummary:N. The session-summary side has no equivalent on its dominant path:
- The
summary task's trigger (ai/daemons/orchestrator/scheduling/summary.mjs) logs pending-summarization:N only on the pending-summarization path (explicit SummarizationJobs markers).
- When there are no markers, it fires via
periodic-sweep with reason periodic-sweep:600000 — no backlog count. The periodic sweep is exactly the path that handles "ordinary unsummarized sessions," so the real session-summary backlog depth is invisible.
Net: we can see the mini-summary backlog drain but are blind to the session-summary backlog (the operator's "we need both").
Fix
- Add
getPendingSessionSummaryCount(db) to summary.mjs: a fail-soft graph-direct count of sessions with AGENT_MEMORY rows but no SESSION_SUMMARY (the real unsummarized-session backlog — parallel to the mini-summary count's "rows missing a miniSummary" semantics, not the capped SummarizationJobs marker fetch).
- Thread it into
buildSummaryTrigger's periodic-sweep reason so every periodic sweep logs the depth, e.g. periodic-sweep:600000 pending-session-summary:N. Wire the count fn in getDueTask (test seam, like #12810).
Acceptance Criteria
Relations
Parallel to #12810 (mini-summary backlog count). Relates to #12819 / #12820 (session-summary silent-gap fix), #12817 LEAF 1.
Authored by Claude Opus 4.8 (Claude Code)
Problem (v13 observability)
#12810 added the mini-summary backlog count to the orchestrator log: the
memory-summary-backfilltask only fires when there's a backlog, so it always logspending-memory-minisummary:N. The session-summary side has no equivalent on its dominant path:summarytask's trigger (ai/daemons/orchestrator/scheduling/summary.mjs) logspending-summarization:Nonly on thepending-summarizationpath (explicitSummarizationJobsmarkers).periodic-sweepwith reasonperiodic-sweep:600000— no backlog count. The periodic sweep is exactly the path that handles "ordinary unsummarized sessions," so the real session-summary backlog depth is invisible.Net: we can see the mini-summary backlog drain but are blind to the session-summary backlog (the operator's "we need both").
Fix
getPendingSessionSummaryCount(db)tosummary.mjs: a fail-soft graph-direct count of sessions withAGENT_MEMORYrows but noSESSION_SUMMARY(the real unsummarized-session backlog — parallel to the mini-summary count's "rows missing a miniSummary" semantics, not the cappedSummarizationJobsmarker fetch).buildSummaryTrigger'speriodic-sweepreason so every periodic sweep logs the depth, e.g.periodic-sweep:600000 pending-session-summary:N. Wire the count fn ingetDueTask(test seam, like #12810).Acceptance Criteria
summaryperiodic-sweep trigger reason includes the uncapped unsummarized-session count.getPendingSessionSummaryCountis fail-soft (returnsnullwhen the table/graph is unavailable) and counts distinctAGENT_MEMORYsessionIds lacking aSESSION_SUMMARY.Relations
Parallel to #12810 (mini-summary backlog count). Relates to #12819 / #12820 (session-summary silent-gap fix), #12817 LEAF 1.
Authored by Claude Opus 4.8 (Claude Code)