Files
jobtrackingapp/docs/redesign/phase-9/p9-requal-01/ATTEMPTS_AND_REPAIRS.md
T
cesnimda 3727a723e8
MariaDB persistence qualification / mariadb (push) Failing after 7s
docs: publish Phase 9 requalification decisions and evidence
2026-10-24 18:32:24 +02:00

5.5 KiB

Retained attempts and qualification-harness repairs

Application source initially used security-pin checkpoint 780b9bc; the subsequently reproduced document-index provider defect is repaired in 2b26953 with its own fresh full regression. The fixture repairs below affect qualification tooling only. Historical acceptance reports are unchanged. Successor counts exclude earlier attempts; no failed startup or short run becomes a passing database, workload or PDF qualification.

Attempt / finding Actual outcome Correction and evidence boundary
Pre-pin NuGet/npm audit Reported Pkcs/Next/Zod advisories Compatible narrow pins in 780b9bc; affected full-suite successors retained separately. Python findings remain OPEN.
First MariaDB browser invocation One native recovery case passed; schema cleanup succeeded Preserved under .artifacts/p9-requal-01/attempts/harness-successor-predecessors/mariadb-browser/. A later affected-harness successor supplies the accepted1-case result; do not add both.
Initial MariaDB HTTP observations Server startup failed: relative API project path resolved against the nested config directory; zero test cases executed; schema cleanup succeeded New nested observations/performance/Linux configs explicitly use the UI working directory, matching the existing RD21 diagnostic convention. The observations successor passes2 cases. Initial setup evidence remains under attempts/harness-successor-predecessors/mariadb-observations/.
Schema ownership before diagnostic write Independent review identified successful CREATE followed by a failing log write could leave cleanup ownership false Record successful CREATE ownership before writing its log. Exact old-checkpoint source replay fails the injected-error regression; corrected source passes both that case and failed-CREATE/no-DROP authority. This is offline harness proof, not an executed data-loss event.
Initial sustained workload setup 250 synthetic applications were created; stored canonical Career JSON omits null object properties while API DTOs include them. Exact cross-format comparison failed before preflight/timer; zero timed reads/navigations; schema cleanup succeeded The fixture compares canonical JSON using the existing StructuredCvProfileJson.SerializePersisted null-property omission. Full API profile assertions and exact SQL before/after equality stay unchanged; SQL/API revision equality is added. CV override null-as-inherit behavior is untouched. Failed evidence and predecessor manifests remain under attempts/performance-canonical-wire-failure/. No15-minute result is inferred from it.
Linux runner error paths, before service execution Review found post-browser SQL failure could retain evidence exit0, and failed log capture could suppress container removal Browser and overall exits are separate; any post-check/cleanup error fails the runner; removal is independent of diagnostic capture; unconfirmed API removal prevents schema DROP. Two offline injected-error tests pass. No earlier Linux runtime PASS is claimed.
MariaDB workload preflight after serializer correction /api/documents returned500: illegal mix of collations in UNION; zero timed requests/navigations; schema cleanup succeeded Actual provider repair, three real RED/GREEN cases, then a new full35-case MariaDB/backend/frontend/browser checkpoint. Entire previous regression and failed preflight retained under attempts/pre-documents-provider-fix/; none is added to successor totals.

The schema-ownership regression itself was debugged with offline fixture corrections for the temporary evidence root and Docker inspect's list envelope. The retained old-source replay then reaches the actual successful-CREATE/log-failure path and fails as expected. These development checks are not added to backend or MariaDB runtime totals.

Initial and successor input manifests are retained. The first successor changes only the performance web-server config among the1042 frozen runtime inputs, plus its affected wrappers; the next changes only the two performance fixture sources. No API, UI source, built export, Release assembly, original PDF oracle or historical test assertion changes during these repairs. Each affected MariaDB lane is rerun against a fresh generated schema; the subsequent application provider repair also triggers a complete fresh regression and rebuild. Final accepted results and hashes belong to validation.json; this history does not waive a failing final gate.

Hosted843/844 retain their original missing-Docker failures. Hosted847 and849 retain expected first-step isolation failures, with no MariaDB test execution. Local Desktop socket recovery is a separate workstation event. Neither its successful startup nor a list-only browser discovery report establishes application acceptance.

Final Linux attempts and fixture successor

attempts/linux-timestamp-baseline/ retains the original1/5 Linux producer result, source/helper manifests and predecessor Windows settings evidence. Four cases differed solely because POST timestamp precision exceeded durable MariaDB datetime(6). At7092697 the fixture reads the complete durable sibling before actions, then retains strict complete-body equality afterward. Windows4/4 and Linux5/5 successors pass; they are never added to whole-suite362. The unchanged Linux output oracle then genuinely fails11/24 fixtures (65 versus60 pages). See LINUX_PDF.md; no tolerance, baseline, API or rendering contract was changed to obtain a pass.