1.7 KiB
Consecutive failed releases (WJ-022)
The real-H2 rollback harness accepts --failures 2. It stages two distinct
candidate manifests B and C descending from known-good A. Each candidate
contains an additional Liquibase migration that persists a schema change and
then fails. The real deployment implementation must restore A and its fresh
database snapshot after each failure.
An identifiable work entry is inserted after A first becomes ready. After B has failed and A is restored, the fixture writes another entry before C is deployed. Both entries must survive C's rollback. This detects accidental reuse of B's older snapshot as well as publication of either failed candidate.
Every round independently verifies partial migration, process termination,
restored database checksums, the selected executable and deployed manifest,
schema and migration history, and maintenance until readiness. The resulting
report contains a separate record for each candidate and restored commit.
The unchanged local service/HTTP boundaries and notification isolation are
described in migration-rollback-acceptance.md.
WJ-022 runs in productionAcceptance alongside WJ-020 and WJ-021. Its report is
build/reports/production/two-failures.json; its JVM logs are in the sibling
two-failures-logs directory, separate from the WJ-021 logs.
Verification: the standalone two-failure probe passed, then all three production Gherkin scenarios / 16 steps passed together on 0.1.81-SNAPSHOT in 2m 18.682s. The targeted Gradle invocation excluded the already-tested JVM suite; the normal CI pipeline retains that mandatory stage. The completion push increments the version to 0.1.82-SNAPSHOT. CI verification of WJ-022 is pending.