1.8 KiB
Failed rollback readiness (WJ-023)
The real-H2 harness adds --fail-rollback. Candidate B first fails after a
persisted Liquibase schema change, as in WJ-021. After the production deployment
algorithm restores the matching database and executable A, the fixture reserves
the test HTTP port. A therefore cannot start its embedded server and exits with
the actual port-in-use error. No production port or service is involved.
The test requires the deployment algorithm to stop the failed rollback process, retain the maintenance flag and deployment journal, and keep public HTTP access at 503. It also verifies that the restored database still contains the saved booking. Both failures must remain in the exception chain.
A separate worker process executes this failure path and deliberately lets the exception escape. The parent requires a nonzero exit status and both the candidate-migration and rollback-readiness errors in the captured output before reporting test success. Thus an accidentally swallowed error or success exit cannot pass. This tests the process/log boundary; the actual CI job passes when the expected failure is correctly observed.
Reports and isolated application logs are in build/reports/production under
failed-rollback*. The worker has its own process group, which is terminated on
timeout. Mail is trapped and push is disabled. Actual Hostsharing/systemd and
operator recovery checks remain separate.
Verification: the standalone failure probe passed with worker exit code 1,
both failures logged, retained maintenance/journal and the saved booking intact.
The combined productionAcceptance -Pproduction=true -x test run on
0.1.83-SNAPSHOT passed all four scenarios / 20 steps in 3m 1.776s. The normal CI
wrapper retains the mandatory JVM/browser checks before this stage. Completion
version: 0.1.84-SNAPSHOT; CI execution of WJ-023 is pending.