- Concept
- Version · 6.0
- Create
DynamoDB transaction retry behavior
Last updated: August 12, 2026
If a changeset's transaction succeeds but Liquibase fails to record it in DATABASECHANGELOG (for example, due to a network interruption), the changeset will appear unrecorded. Retrying has different outcomes depending on how much time has passed.
Retrying within 10 minutes
Retrying within 10 minutes is safe. Liquibase records the changeset in DATABASECHANGELOG and reports success. Your data is in the correct state.
Note: Liquibase logs show the changeset as successful. There is no indication in the logs that the data change had already been applied.
Retrying after 10 minutes
After 10 minutes, the safety window has expired. Liquibase attempts to apply the changeset again.
INSERT statements fail with a duplicate key error. No data is corrupted.
DELETE statements and SET statements that assign a fixed value re-apply safely.
Non-idempotent UPDATE statements (for example,
SET counter = counter + 1or appending to a list) execute again and can corrupt data.
Workaround: Retry within 10 minutes when possible. If your changeset contains non-idempotent UPDATE statements and you cannot retry within 10 minutes, verify the current state of your data manually before retrying.
runInTransaction="false"
Changesets that use runInTransaction="false" have no retry protection. If a statement fails mid-changeset, any statements that already ran are permanently committed. There is no safety window on retry.