fix(storage): stop async raw writer clobbering revision evidence

[Sinity]

Summary

Deletes the async SQLite backend's hand-rolled save_raw_session INSERT and delegates to the single canonical durable-tier writer, closing a latent revision-evidence clobber.

Problem

SQLiteRawMixin.save_raw_session (polylogue/storage/sqlite/async_sqlite_raw.py) hand-rolled its own 18-column INSERT OR REPLACE into raw_sessions, while the production writer (polylogue/storage/sqlite/queries/raw_writes.py, reached via RepositoryRawMixin from the real acquire path) uses a 28-column INSERT OR IGNORE that also carries revision-authority evidence (logical_source_key, revision_kind, source_revision, predecessor_source_revision, predecessor_raw_id, baseline_raw_id, append_start_offset, append_end_offset, acquisition_generation, revision_authority). A re-save of an existing raw_id through the async path would silently reset all of those columns to defaults on the durable source tier, destroying revision lineage. The mixin also wrote directly into blob_refs, duplicating the separate canonical write_source_raw_session_blob_ref path and its lifecycle.

No production caller of the async mixin's method was found — the real acquire path (AcquisitionService → persist_raw_record → SessionRepository.save_raw_session) already goes through RepositoryRawMixin, which already delegates to the correct writer. The clobber was latent (reachable only via direct backend.save_raw_session calls, as many tests do), one refactor away from being wired into production.

Solution

Deleted the hand-rolled SQL body and made SQLiteRawMixin.save_raw_session delegate to queries/raw_writes.save_raw_session, matching what RepositoryRawMixin.save_raw_session already does — single source of truth for the INSERT, no possibility of column-list divergence. Removed now-unused imports (hashlib, origin_from_provider, _timestamp_ms) and the now-dead _source_db_path type stub.

Added two regression tests in tests/unit/storage/test_raw.py:

• test_writer_insert_covers_every_live_raw_sessions_column: introspects the live raw_sessions DDL via PRAGMA table_info and asserts the canonical writer's INSERT column list matches exactly — fails if a future migration adds a column the writer doesn't reference, or vice versa.
• test_async_backend_has_no_second_raw_sessions_insert: fails if a hand-rolled INTO raw_sessions INSERT reappears in the async mixin.
• test_resave_never_alters_revision_evidence: saves a record with populated RawRevisionEnvelope (byte-proven authority), re-saves the same raw_id with a bare record, and asserts the original revision evidence survives unchanged.

Verification

• devtools test tests/unit/storage/test_raw.py tests/unit/storage/test_raw_authority_ledger.py tests/unit/storage/test_duplicate_raw_identity_repair.py → 60 passed
• Anti-vacuity: reverted the source fix (keeping the new tests) via git stash — exactly test_async_backend_has_no_second_raw_sessions_insert and test_resave_never_alters_revision_evidence failed; the DDL-parity test passed (it targets raw_writes.py, which was already correct).
• devtools test on every other backend.save_raw_session call site (parsing service, quarantine fixtures, parse tracking, search misc, storage twins, daemon ingest idempotency, ingest pipeline correctness) → all pass except 6 pre-existing test_parsing_service.py failures (Mock has no attribute 'drive_config'), confirmed to reproduce identically on pre-fix code via the same stash technique — unrelated to this change.
• devtools verify --quick → exit 0 (format, lint, mypy --strict, render-all, layering, closure-matrix, schema roundtrip, manifests, ci-workflows, doc-commands, docs-coverage, test-infra-currency, clock-hygiene, timeout-overrides, degrade-loudly).

Ref polylogue-vwia

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Review limit reached

@Sinity, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 27 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: d9d322a6-2bc8-4165-9e1f-3d91b24df754

📥 Commits

Reviewing files that changed from the base of the PR and between 590f012 and b9f84bb.

📒 Files selected for processing (2)

• polylogue/storage/sqlite/async_sqlite_raw.py
• tests/unit/storage/test_raw.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/fix/hardening-sweep

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}