Liquibase ChangeSet Execution with External Retry Mechanisms: Preventing Duplicate Writes

Answer

Liquibase does not expose any runtime flag or table state that indicates a changeSet was partially applied when runInTransaction=false. The absence of a row in DATABASECHANGELOG only tells you that the changeSet did not finish successfully; it does not guarantee that no database changes were made.

Confirmed facts

• Liquibase writes to DATABASECHANGELOG only after a changeSet completes without error, regardless of the runInTransaction setting.
• When a changeSet fails with runInTransaction=false, any DDL or DML that executed before the failure may already be committed (especially for databases that auto‑commit DDL).
• External retry mechanisms that rely solely on the missing DATABASECHANGELOG entry can therefore re‑execute a changeSet that has already made partial changes, leading to duplicate or conflicting writes.

Likely explanation

Because Liquibase does not track partial execution, the safe way to coordinate with an external retry system is to make the changeSet itself idempotent or to introduce an external marker that the retry logic checks before re‑running the changeSet.

Steps to prevent duplicate writes

1. Make the changeSet idempotent: add a preCondition that checks for the existence of the objects the changeSet creates or modifies (e.g., <preConditions onFail="MARK_RAN"><tableExists tableName="my_table"/></preConditions>).
2. If idempotency is impractical, create a simple marker table (or use an existing one) that your external retry logic queries before invoking Liquibase. Insert a row only after the changeSet succeeds.
3. When possible, set runInTransaction=true for the changeSet so that any failure rolls back automatically, eliminating the need for external duplicate‑write guards.
4. Verify behavior in a sandbox: run the changeSet with runInTransaction=false, let it fail, then query DATABASECHANGELOG and inspect the target schema to see what partial changes remain.

Missing diagnostic detail

To confirm whether any partial DDL effects persist after a failure, please specify the target database and JDBC driver version (e.g., PostgreSQL 15 with pgJDBC 42.7). This information determines whether DDL auto‑commit occurs and influences the recommendation.