Skip to content

feat(ops): admit existing managed SQLite databases with target Server checks - #2286

Open
knqiufan wants to merge 3 commits into
masterfrom
codex/managed-database-admission-2115
Open

knqiufan wants to merge 3 commits into
masterfrom
codex/managed-database-admission-2115

Conversation

@knqiufan

@knqiufan knqiufan commented Oct 28, 2026 •

Copy link
Copy Markdown
Collaborator

Which issue or RFC does this PR close?

Related issue: #2115 — managed local runtime bootstrap (database admission follow-up to #2203).

This PR completes the existing-database admission integration: compatible storage can start through the verified target Server; changed or incompatible storage is rejected without migration or source writes. The broader #2115 remains open: clean Windows/macOS bootstrap using published, qualified resources and installed acceptance remain outstanding. Keep #2115 open until that evidence is linked.

Parent: #2114. Contract: RFC #1733. Resource production: #2288 / #2112. Desktop native bridge: #2289 / #2116.

Rationale for this change

Managed installation can initialize a new SQLite database, but subsequent start/restart currently rejects every existing database as unknown. This change admits an existing database only when the verified target Server can establish complete compatibility, without migrating or modifying the source database.

What changes are included in this PR?

  • Add a bounded private snapshot admission path using the installed target Server's schema, domain, configuration, history and recovery checks.
  • Preserve committed WAL content while keeping SQLite connections away from the original database and its sidecars.
  • Bind approved starts to the resource identity and database evidence, and reject changed, incomplete or incompatible state.
  • Keep passive inspection and same-version program repair independent from expensive admission and preserve data and explicit-stop state.
  • Document limits and add real SQLite / child-process regression coverage.
  • Update the persistence compatibility review digest without changing the upgrade-required policy or acceptance matrix.

Are there any user-facing changes?

Compatible existing managed SQLite storage can be started again. Normal writes invalidate an approved plan: for a busy database, stop the service, obtain a fresh start plan after writes stop, and approve it. Rejected restart plans leave the running service unchanged. Unsupported storage requires explicit maintenance; no automatic migration, data deletion or runtime upgrade is introduced. This does not complete resource publication or installed-platform acceptance for #2115.

How was this change tested?

  • Claude Code CI regression: Python 3.12 unit job raised the expected slow-response timeout but exceeded the test's scheduler-sensitive 0.5-second wall-clock assertion (0.607 seconds). Real slow HTTP coverage is retained; a separate controlled-clock test enforces the unchanged 0.1-second shared body deadline and incomplete body consumption. Removing the cumulative deadline in a mutation probe makes that regression fail. uv run --no-sync pytest -q tests/claude_code_plugin: 97 passed; final make check passed. No production timeout or database admission behavior changed. Open Code Review's delegate mode explicitly reviewed the test-only fix because default remote selection excludes tests; no findings remain.

  • make check: passed on the final tree, including lock consistency, all pre-commit hooks, both type-check scopes, upgrade policy, workflow pins and 61 integration-manifest tests.

  • uv run --no-sync pytest tests/test_ops_database_admission.py tests/e2e/test_managed_database_admission.py tests/test_ops_local_policy.py tests/test_ops_installer.py tests/test_ops.py tests/test_service_ops_boundary.py tests/test_managed_startup_admission.py tests/e2e/test_managed_runtime_repair.py -q: 146 passed, 1 platform skip.

  • Post-review uv run --no-sync pytest tests/test_ops_database_admission.py tests/e2e/test_managed_database_admission.py -q: 28 passed, including malformed child replies, source disappearance and busy-write stop/fresh-start recovery; independently rerun with the same result.

  • Archive/startup/read-consistency/full-Server/vector migration regression selection: 39 passed, 6 external-backend skips.

  • Actual SQLite and target subprocess checks cover WAL-only schema and Memory history, unchanged source DB/WAL/SHM bytes and timestamps, stale approvals, configuration/profile/history/recovery rejection, damaged-target repair, output bounds and inherited-pipe timeout handling. Service management and managed resource distribution in these tests are simulated.

  • Local warm-filesystem cost sample: 2,000 public Memory records / 4,000 revisions in a 168.4 MiB database; three full admissions took 3.78–3.86 seconds with unchanged source SHA-256. This excludes resource verification/native service cost and is not a maximum-size or other-platform timing guarantee.

  • Open Code Review CLI reviewed the branch and returned a partial result because two selected files exceeded its context-compression threshold. The plugin's delegate workflow then independently reviewed all 11 changed files, including docs/tests, with 100% coverage and no remaining blocking findings. Accepted response/race normalization findings were fixed and rechecked; the busy-writer boundary is explicit and tested. The extra pre-dispatch admission on pending installation remains an intentional conservative check.

Validation host: macOS arm64, Python 3.12.15. Real Windows/macOS service lifecycle, signed production resources, clean-machine installation and external-backend upgrade acceptance remain separate; no service registration was changed on the host.

AI usage statement

Implemented with Codex using GPT-6 Astra, with earlier GPT-6 Luna investigation and a primary agent coordinating integration. Review used Open Code Review's configured CLI reviewer plus its delegate workflow with an independent GPT-6 Astra agent. Review repairs and final validation are recorded above.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant