cesnimda
3.9 KiB
MariaDB and RD21 — 2026-10-27
The disposable real MariaDB lane passed 79/79, zero skips, with successful startup, locked restore, test and owned-container cleanup (.artifacts/cv-integration-qa/lifecycle-green-01/run.json). The entry baseline was 70/70; the first mapping checkpoint added two provider cases and lifecycle qualification added seven. These are successive totals, not additive runs. Final source-freeze qualification is reported separately in REGRESSION_RESULTS.md.
Canonical writes retain the existing Career Profile transaction, expected revision, relational projections, history and durable import receipt. No historical CV, CV override, submitted package or frozen letter is rewritten. Mapping-only multi-record imports into an empty profile cover contacts/links, two jobs, two education records, languages, certification/project and long-tail sections. Actual readback verifies child rows, source identifiers, incomplete date precision and rejected fields. Exact replay produces no extra revision. Injected projection failure rolls all changes back.
Reproduced lifecycle races
Independent contexts use finite database-command barriers after SELECT; tests do not substitute an in-memory provider. The retained RED attempt had seven failures and 72 passes. Apply after a competing discard actually raised MariaDB 1020 (record has changed since last read) rather than silently committing. Reverse discard/apply, stale retention, cancel acknowledgement and retries of discarded/expired/applied jobs also failed their assertions.
The run status is now an EF concurrency token, with matching snapshot metadata and no physical column or migration. A losing discard returns 409. Apply handles EF stale writes and narrowly identified MariaDB 1020 after the established transaction rollback. Retention retries each conflicting run at most twice and recomputes cleanup from reloaded state; it preserves applied candidate/receipt data while expiring the source file. Cancellation cannot overwrite a discarded terminal state. Retry claims only an eligible mutable CV run atomically before queueing; terminal runs cannot reopen.
The GREEN cases confirm no canonical write after discard, no discard after apply, retained applied receipts and exact replay after retention, terminal cancellation preservation and rejected terminal retries. Existing owner/tenant and first/existing-profile revision tests remain enabled. A displayed success still requires confirmed durable application.
Final actual connection-loss qualification
The final current-source lane passes 80/80, zero skips (mariadb-final-01/mariadb.trx); startup, locked restore, test and owned-container cleanup exit0. The additional test terminates only its own active connection's numeric ServerThread in the guarded disposable database, after all writes but before outer commit. A returned success or a hung request cannot qualify: it requires a real failure, rejects timeout, checks revision0/pending review/no receipt/no skill or history/unchanged Identity pointer, then verifies exact retry and replay produce one durable revision and one skill. This is actual MariaDB session loss, not a mocked provider exception or a whole-server/power-loss experiment. No production connection is used.
The extra test is a separately bound test-only addition after the full application freeze; all original source hashes remain unchanged. The final provider run includes the seven lifecycle cases and all earlier mapping/rollback/owner/revision cases. A separate warmed sample reports 51.055ms for reviewed application including validation, merge, transaction and Identity projection; it is not a latency SLA.
This qualifies the exercised disposable MariaDB behavior. It does not establish hosted CI, production database behavior, power-loss recovery or server filesystem/backup integrity. Historical RD21 evidence is preserved; current-source focused races complement rather than replace its full regression lanes.