fix(storage): stop title_source=unknown from defeating the structural label - #3421
Conversation
… label Problem: polylogue-cijx.4 decision 3 wired session_structural_label_for_ session into ArchiveStore._summary_from_row, but the "is this a real title" check only asked whether sessions.title was non-blank. Claude Code's parser initializes title to the raw composed session id (a bare UUID, or "<uuid>:agent-<hash>" for a subagent) and only promotes title_source off UNKNOWN when a real signal is found. So a title_source= 'unknown' row still carries a non-blank title, and the pre-blank-only check accepted it as a "provider title" -- the exact raw-id echo decision 3 was supposed to replace. Measured live (/realm/db/polylogue, read-only): 7,501 of 15,401 root sessions (48.7%) carry title_source='unknown', which made the structural-label fallback dead code for all of them. What changed: _summary_from_row now only treats a non-blank title as real when title_source is 'origin', 'heuristic', or 'user'; 'unknown' (and the label's own prior 'path' output, for idempotency) fall through to the structural label. Verification: devtools test tests/unit/storage/test_title_source_ queryable.py tests/unit/insights/test_session_label.py tests/unit/ archive/test_repo_identity.py -- 29 passed. devtools verify --quick -- 19 steps, exit 0. Live re-measure after the fix (read-only against /realm/db/polylogue/index.db): among root sessions with resolved file-touch evidence (a dominant repo-relative path -- the population the bead's original 3.5%/max-10 baseline was measured against), collision rate is 3.28% (78/2377), max group size 37. The much larger raw collision figure across ALL title-less sessions (76.46%, dominated by a 5,233-session "0 msgs" cluster) reflects genuinely evidence-free stub/ empty sessions, not a labeling defect -- reported in full on polylogue-cijx.4. Ref polylogue-cijx.4
polylogue-cijx.4's decisions 1-3 (repo identity, repo-relative paths, structural label projection) were already substantially landed on master before this lane started (PR #3390 fallout); this lane's own contribution is the archive.py title-provenance fix in eb5f904 plus the live AC5 collision measurement, both recorded as a comment on polylogue-cijx.4. Decision 4 (default result unit = top-level session) needs a separate, higher-blast-radius change (DSL grammar + CLI default-behavior audit across every query surface) -- split out as polylogue-oqib rather than attempted inside this lane's diff. Ref polylogue-cijx.4
|
Warning Review limit reached
Next review available in: 26 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 05941dc319
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # dead code for all of them. ``title_source='path'`` is the structural | ||
| # label's own prior output; treating it as "not a real title" keeps this | ||
| # idempotent on rebuild instead of freezing a stale message count. | ||
| has_real_title = bool(raw_title and raw_title.strip()) and raw_title_source in {"origin", "heuristic", "user"} |
There was a problem hiding this comment.
When a stored title has no title_source, this whitelist now treats it as synthetic. That is normal production data for several origins: polylogue/sources/parsers/chatgpt.py:1101-1106, for example, copies the provider's conversation title into ParsedSession without setting title_source, and the ChatGPT assembly does not add it. Consequently read_summary and list_summaries replace genuine ChatGPT titles with structural labels such as "1 msgs", propagating through CLI/MCP/API summary surfaces. Restrict the fallback to title_source='unknown', or stamp every affected parser before enforcing this whitelist.
Useful? React with 👍 / 👎.
# Conflicts: # .beads/issues.jsonl
1 participant
Summary
Fixes the one concrete production bug found while auditing
polylogue-cijx.4 ("Repo identity, path normalization and readable labels
are ONE batch"): the session structural-label projection (decision 3 of
that bead) was wired into the summary read path but never actually fired,
because the "does this session have a real title" check only asked
whether
sessions.titlewas non-blank — not whether it came from a realsource.
Problem
polylogue-cijx.4decisions 1-3 (repo identity keyed on the normalizedremote, repo-relative paths, and a read-time structural-label projection)
turned out to already be substantially landed on
masterbefore thislane started — they shipped as part of PR #3390's larger diff (commit
5e23e6abf, "index v46 wire-evidence batch"), with real test coverage(
tests/unit/archive/test_repo_identity.py,tests/unit/insights/test_session_label.py).Auditing that existing implementation against a read-only copy of the
live archive (
/realm/db/polylogue/index.db) found the label was dead inproduction:
_summary_from_rowinstorage/sqlite/archive_tiers/archive.pytreated any non-blanksessions.titleas a genuine provider title. But Claude Code's parser(
sources/parsers/claude/code_parser.py, out of this lane's write scope —owned by the polylogue-pbuh lane) initializes
titleto the raw composedsession id (a bare UUID, or
"<uuid>:agent-<hash>"for a subagent) andonly promotes
title_sourceoffUNKNOWNwhen a real signal (humanmessage,
agent-name,ai-title,custom-title) is found. So atitle_source='unknown'row still carries a non-blank title — exactlythe raw-id echo the bead's motivating text complains about
("
agent-ad682bc849a1cd0f0 - 27f - 499m— worse than the UUID itreplaces").
Measured live, read-only: 7,501 of 15,401 root sessions (48.7%) carry
title_source='unknown'. The structural-label fallback never fired forany of them.
Solution
_summary_from_rownow only treats a non-blanksessions.titleas areal title when
title_sourceisorigin,heuristic, oruser.unknown(and the label's own priorpathoutput, for rebuildidempotency) fall through to
session_structural_label_for_session.Modules touched:
polylogue/storage/sqlite/archive_tiers/archive.py(the fix),
tests/unit/storage/test_title_source_queryable.py(newregression test reproducing the exact Claude Code raw-id-fallback shape),
.beads/issues.jsonl(AC disposition + a new follow-up bead).AC4 of polylogue-cijx.4 (default result unit = top-level session) is
explicitly NOT addressed here — investigated and found to require a
separate, higher-blast-radius change (Lark DSL grammar wiring for a
root:field, which currently doesn't exist on any query surface despitethe underlying
Session.is_root/parent_session_idplumbing alreadybeing correct, plus a default-behavior decision affecting every
unfiltered
find/list()/MCPquerycall). Split out aspolylogue-oqibrather than folded into this diff. Full AC1-5disposition recorded as a comment on
polylogue-cijx.4.Not a
polylogue-pbuhoverlap: pbuh's typedai-title/agent-name/pr-linksidecar-record work is a different, complementary fix (makingtitle_sourcelegitimatelyoriginmore often) — this PR fixes the readpath's consumption of
title_source, regardless of how it got there.Verification
Live collision-rate re-measurement (AC5 of polylogue-cijx.4), read-only
against
/realm/db/polylogue/index.db(15,401 root sessions), after thisfix:
repo-relative path — the population the bead's original 3.5%/max-10
baseline was measured against): 3.28% collision (78/2,377), max group
37.
figure is dominated by a 5,233-session cluster of genuinely
evidence-free (zero-message, no repo, no file touch) sessions
collapsing to the honest label
"0 msgs"— not a labeling defect. Fullnumbers and a note about whether 5,233 zero-message root sessions is
itself a data-quality question are on the
polylogue-cijx.4comment.Not run: the full non-quick
devtools verify --all(testmon wasn'tseeded on this worktree; ran the exact touched-file selection instead per
repo convention).
Ref polylogue-cijx.4