|
2300 | 2300 | {"id":"coding_agent_session_search-gh364-watch-once-false-oom-quarantin-trxfe","title":"watch-once falsely OOM-quarantines a 36MB Codex session with abundant host memory (GH #364)","description":"GH #364: cass index --watch-once <single 36.7MB/7678-message Codex session> under systemd MemoryHigh=8G/MemoryMax=16G with ~89GiB MemAvailable records the source in watch_ingest_poison.jsonl with reason=watch-ingest-out-of-memory and quarantines it as same-version irreducible. Looks like per-conversation ingestion budgeting/accounting failure, not real OOM. Asks: (1) stream/chunk oversized conversations in watch-once with per-chunk accounting; (2) distinguish budgeting refusal from allocator/cgroup OOM in the structured result; (3) resumable per-conversation progress; (4) precise retry eligibility in cass diag --json --quarantine. Related epic: coding_agent_session_search-cass-fleet-resilience-20260608-uojcg.3. Classification sites: src/indexer/mod.rs ~:21635/:22094/:23191 (watch-ingest-out-of-memory).","notes":"Poisoning half fixed in ef7e2595: ample reported memory now always defers (never quarantines) a single-conversation NoMem on both watch and non-watch paths, regardless of size; poison-path tests pin forced pressure via CASS_WATCH_OOM_REAL_PRESSURE_RESERVE_BYTES; new gate test pins the #364 shape. Remaining on this bead: chunked single-conversation ingest with per-chunk accounting + resumable per-conversation progress (the piece that makes the conversation actually ingest under a tight cgroup budget), and optionally recording pressure/attribution in poison records (schema+goldens pass).","status":"in_progress","priority":1,"issue_type":"bug","created_at":"2026-07-29T07:13:15.047812992Z","created_by":"ubuntu","updated_at":"2026-08-02T02:17:34.882850998Z","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2301 | 2301 | {"id":"coding_agent_session_search-gh362-fts5-overlong-term-corruption-h9rce","title":"frankensqlite FTS5 hard-fails on >64KiB terms; corrupts %_data and blocks every repair path (GH #362)","description":"GH #362: any corpus containing a whitespace-delimited token >65535 bytes (91,548B observed; minified JS bundles/base64 blobs in tool outputs — 173 of 8,261 real session files contain >60KB tokens, so this is normal data for this domain) deterministically fails 'fts5: corrupt %_data record: segment leaf term offset exceeds u16' during FTS insert. Every repair path fails: index --full (exit 9), doctor --rebuild-canonical-fts --yes, --force-rebuild, and DROP+from-scratch rebuild (which also spun 7h at 100% CPU with no progress output). Stock C-SQLite FTS5 does not hard-fail on the same content. PRIMARY FIX in frankensqlite (/data/projects/frankensqlite): the FTS5 writer must truncate or skip terms exceeding the u16 leaf-offset limit instead of failing the segment write. CASS-SIDE: add a regression fixture with an overlong token; consider a defensive pre-insert term-length cap in the FTS maintenance path; rebuild should emit rows/phase progress. Reporter offered the offending message content privately and a scanner for fixtures. Root context also explains part of GH #355/#359 failure chains.","status":"closed","priority":0,"issue_type":"bug","created_at":"2026-07-29T07:13:38.223651032Z","created_by":"ubuntu","updated_at":"2026-07-29T20:42:07.360352114Z","closed_at":"2026-07-29T20:42:07.355821317Z","close_reason":"Pinned to hotfix 62a58ee3 (f9cc3294 family + FTS5 overlong-term skip) in 19b664d2 with the full validated pass: check, clippy, compat gates 34, storage parity 37, storage 72, goldens 49+16, and the new rebuild_canonical_fts_survives_overlong_term_in_corpus fixture (91,548-byte token through the real repair path). Full-forward bump to async-first upstream main remains a separate porting pass.","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2302 | 2302 | {"id":"coding_agent_session_search-gh345-329-fts-rebuild-allocation-bou-jd3zj","title":"FTS5 shadow rebuild/creation OOMs on multi-million-message archives despite huge free RAM (GH #345, #329)","description":"GH #345: doctor --rebuild-canonical-fts on a 22GB/2M-message archive: dry-run runs 22+min at ~18GiB RSS; --yes under MemoryMax=24G fails 'creating fts_messages inside atomic rebuild: out of memory' with the error originating at execute_compat(FTS5_REGISTER_SQL) — unbounded allocation in FrankenSQLite FTS virtual-table registration; the resumable incremental catch-up also failed to commit its first batch in 8m26s/17.6GiB (each contentless FTS insert re-encodes the whole table — frankensqlite bd-sf8dx). GH #329: index --full on 967k-1.2M message corpora fails the post-index fallback-FTS repair with internal 'out of memory' at ~10-30GB RSS while the host has 600GiB+ free; canonical DB and Tantivy publish remain intact; doctor treats absent DB FTS as healthy. PRIMARY FIX in frankensqlite: allocation-bounded FTS5 registration + incremental persistence (bd-sf8dx). CASS-SIDE: bounded/estimating dry-run with progress; documented capacity expectations; consider making the post-index fallback-FTS repair optional/skippable on huge corpora since Tantivy serves lexical.","status":"open","priority":1,"issue_type":"bug","created_at":"2026-07-29T07:13:38.482896778Z","created_by":"ubuntu","updated_at":"2026-07-29T07:13:38.482896778Z","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2303 | | -{"id":"coding_agent_session_search-gh353-status-search-fingerprint-spli-wjpv5","title":"status reports checkpoint.db_matches=true while search defers repair on storage-fingerprint mismatch forever (GH #353)","description":"GH #353 (+ Linux repro comment): every cass search logs 'lexical checkpoint storage fingerprint no longer matches active database' and defers heavyweight repair to cass index; cass status --json simultaneously reports checkpoint.db_matches=true, index fresh, current_db_fingerprint=null, matches_current_db_fingerprint=null — so plain cass index sees a healthy state and exits 0 without repairing. Repair is deferred on every query and never runs; new sessions stay unsearchable until manual index --full (user-visible: term present only in post-drift sessions returns nothing). Mechanics: search-side check = lexical_storage_fingerprint_for_db vs checkpoint.storage_fingerprint via lexical_storage_fingerprints_match (src/lib.rs ~:23486-23528); status-side checkpoint block computed separately in src/search/asset_state.rs (inspect_search_assets, compute_lexical_fingerprint gated by include_counts). Fix: one shared comparison for both surfaces; status must compute (or truthfully report not-computed) the same storage fingerprint search uses, and plain cass index must honor the search-side mismatch as repair-needed (or the deferral hint must name index --full).","notes":"Deepened analysis (2026-07-29 session 2): the deadlock is CIRCULAR. One aborted rebuild leaves a stale checkpoint fingerprint; on every subsequent plain incremental, tantivy_requires_rebuild sees the mismatch -> should_defer_incremental_authoritative_lexical_repair fires (DB > 1GiB cap) -> needs_rebuild forced false -> the final-checkpoint-refresh skip branch (indexer/mod.rs ~14945) preserves the stale fingerprint -> repeat forever. IMPORTANT: do NOT fix by refreshing the checkpoint after inline updates — the #353 Linux repro (incremental_inline reported, yet post-drift terms unsearchable) proves inline-strategy-reported does not guarantee the published generation absorbed the delta; refreshing would mask real staleness. The #289 fix already narrowed the deferral to rebuild-required runs. Safe fix shape: a bounded index<->DB equivalence verification (the publish pipeline already emits equivalence evidence artifacts, persist_lexical_refresh_ledger / equivalence evidence ~:6464) that, when it PASSES, permits a checkpoint-metadata-only repair (rewrite fingerprint without rebuild); when it fails, escalate honestly to the --full recommendation (already wired via gh359 hint + deferral notice). Status-side truthfulness (db_matches naming / null comparison) remains the secondary fix; goldens pass needed.","status":"open","priority":1,"issue_type":"bug","created_at":"2026-07-29T07:13:38.710111219Z","created_by":"ubuntu","updated_at":"2026-07-29T22:42:52.647871671Z","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
| 2303 | +{"id":"coding_agent_session_search-gh353-status-search-fingerprint-spli-wjpv5","title":"status reports checkpoint.db_matches=true while search defers repair on storage-fingerprint mismatch forever (GH #353)","description":"GH #353 (+ Linux repro comment): every cass search logs 'lexical checkpoint storage fingerprint no longer matches active database' and defers heavyweight repair to cass index; cass status --json simultaneously reports checkpoint.db_matches=true, index fresh, current_db_fingerprint=null, matches_current_db_fingerprint=null — so plain cass index sees a healthy state and exits 0 without repairing. Repair is deferred on every query and never runs; new sessions stay unsearchable until manual index --full (user-visible: term present only in post-drift sessions returns nothing). Mechanics: search-side check = lexical_storage_fingerprint_for_db vs checkpoint.storage_fingerprint via lexical_storage_fingerprints_match (src/lib.rs ~:23486-23528); status-side checkpoint block computed separately in src/search/asset_state.rs (inspect_search_assets, compute_lexical_fingerprint gated by include_counts). Fix: one shared comparison for both surfaces; status must compute (or truthfully report not-computed) the same storage fingerprint search uses, and plain cass index must honor the search-side mismatch as repair-needed (or the deferral hint must name index --full).","notes":"Deepened analysis (2026-07-29 session 2): the deadlock is CIRCULAR. One aborted rebuild leaves a stale checkpoint fingerprint; on every subsequent plain incremental, tantivy_requires_rebuild sees the mismatch -> should_defer_incremental_authoritative_lexical_repair fires (DB > 1GiB cap) -> needs_rebuild forced false -> the final-checkpoint-refresh skip branch (indexer/mod.rs ~14945) preserves the stale fingerprint -> repeat forever. IMPORTANT: do NOT fix by refreshing the checkpoint after inline updates — the #353 Linux repro (incremental_inline reported, yet post-drift terms unsearchable) proves inline-strategy-reported does not guarantee the published generation absorbed the delta; refreshing would mask real staleness. The #289 fix already narrowed the deferral to rebuild-required runs. Safe fix shape: a bounded index<->DB equivalence verification (the publish pipeline already emits equivalence evidence artifacts, persist_lexical_refresh_ledger / equivalence evidence ~:6464) that, when it PASSES, permits a checkpoint-metadata-only repair (rewrite fingerprint without rebuild); when it fails, escalate honestly to the --full recommendation (already wired via gh359 hint + deferral notice). Status-side truthfulness (db_matches naming / null comparison) remains the secondary fix; goldens pass needed.","status":"in_progress","priority":1,"issue_type":"bug","created_at":"2026-07-29T07:13:38.710111219Z","created_by":"ubuntu","updated_at":"2026-08-02T03:35:31.745252115Z","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2304 | 2304 | {"id":"coding_agent_session_search-gh357-opencode-remote-double-tag-zev6j","title":"OpenCode connector re-scans local opencode.db under remote SSH source contexts (GH #357)","description":"GH #357: with a remote SSH source whose paths include ~/.local/share/opencode, local ~/.local/share/opencode/opencode.db sessions are indexed twice: once source_id=local and once source_id=<remote>. Remote mirror content itself is tagged correctly; the pollution is the local canonical DB being re-scanned in the remote scan context. Likely cause: FAD OpenCodeConnector falls back to canonical local detection roots when the ScanRoot points at the remote mirror (README notes OpenCode 'scans recursively from home'). Fix in franken_agent_detection opencode.rs scan(): honor ctx roots exclusively when a non-local ScanRoot is supplied; add cass-side regression test with a remote-mirror fixture (tests/e2e_sources.rs / multi_source_integration.rs).","status":"closed","priority":2,"issue_type":"bug","created_at":"2026-07-29T07:14:02.061063218Z","created_by":"ubuntu","updated_at":"2026-07-29T15:21:39.596871671Z","closed_at":"2026-07-29T15:21:39.593084143Z","close_reason":"Fixed: watchdog liveness in 368467d6 (activity ticks from pipeline runtime + prep steps, finalize grace for active-rebuild hand-off, regression test); OpenCode remote-root isolation upstream in FAD f7f38440, pinned by e2151f95. All gates green.","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2305 | 2305 | {"id":"coding_agent_session_search-gh351-kimi-code-current-format-dcpuc","title":"Kimi connector: support current Kimi Code layout ($KIMI_CODE_HOME/~/.kimi-code, nested agents/*/wire.jsonl, new event envelope) (GH #351)","description":"GH #351 (+confirming comment): current Kimi Code CLI (0.28-0.29) writes $KIMI_CODE_HOME (default ~/.kimi-code)/sessions/<workDirKey>/<sessionId>/agents/<agent>/wire.jsonl with session_index.jsonl + state.json (title/createdAt/workDir/agents), and a new event envelope (turn.prompt, context.append_message, content.part, llm.request). The existing FAD kimi.rs connector only handles the legacy ~/.kimi/sessions/<hash>/<uuid>/wire.jsonl layout + TurnBegin/ContentPart/ToolCall schema, so current sessions are invisible. Work is in franken_agent_detection (kimi.rs): add the new probe root + KIMI_CODE_HOME override, parse the modern envelope, source metadata from state.json/session_index.jsonl, define sub-agent policy (index subagent transcripts with collision-free IDs or document main-only). Then FAD rev bump in cass + fixtures. Issue body includes representative sanitized wire events; a commenter offered a PR — per policy do not merge; implement independently (their schema notes are useful intel).","status":"closed","priority":2,"issue_type":"feature","created_at":"2026-07-29T07:14:02.328532129Z","created_by":"ubuntu","updated_at":"2026-07-30T01:17:48.710682482Z","closed_at":"2026-07-30T01:17:48.710520696Z","close_reason":"FAD f685a69 (dual-layout kimi) + 1a25887 (omp probe roots + subagent transcripts), pinned by the kimi-bump commit. FAD suite 999 passed; cass connector_kimi 10/10 incl. new end-to-end modern test; agent_detection_completeness 10/10; full check clean.","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
2306 | 2306 | {"id":"coding_agent_session_search-gh350-watch-once-corpus-wide-work-z154d","title":"watch-once on one changed session does corpus-wide work on large archives (GH #350)","description":"GH #350: on a 16k-conversation/9.8GB archive, cass index --watch-once <single 5MB Codex session> ran 5+min at ~1 CPU without completing; status showed processed_conversations=16301/16301 — work proportional to the corpus, not the changed path. Combined with plain incremental deferring lexical repair on large DBs (deferred_authoritative_db_rebuild), a safe 10-minute scheduled refresh is impossible: plain incremental is a lexical no-op, targeted incremental is unbounded. Expected: watch-once work bounded by supplied paths, or a truthful upfront verdict that a full repair is required. Related: e9fd4ecd (skip unchanged watch-once startup maintenance) helped startup, not the scan. Investigate watch_once path in src/indexer/mod.rs (watch-once ingest + publish_semantic_watch_once_artifact + lexical strategy selection).","status":"open","priority":1,"issue_type":"bug","created_at":"2026-07-29T07:14:02.559624128Z","created_by":"ubuntu","updated_at":"2026-07-29T07:14:02.559624128Z","source_repo":"coding_agent_session_search","source_repo_path":"/data/projects/coding_agent_session_search","compaction_level":0,"original_size":0} |
|
0 commit comments