[C4GT Community]: AMRIT-DB — Skip reapplying successful Flyway migrations when checksum changes

[drtechie]

Description

When Flyway migrations are already applied and marked successful in flyway_schema_history, subsequent changes to migration files (or their contents) alter the file checksum and cause Flyway validation errors on service startup. This ticket requests a change so that migrations which have been applied successfully are skipped from causing checksum validation failures when the file content changes locally. The change will allow developer workflows (editing local migration files for non-production development) and deployments to avoid failing due to altered checksums for already-applied migrations.

Reference: https://documentation.red-gate.com/flyway/flyway-blog/older-posts/customize-validation-rules-with-ignoremigrationpatterns

---

Goals

• Prevent Flyway from failing startup when a previously applied migration file's checksum differs from the recorded checksum.
• Document the change and test instructions for developers and DevOps.

---

Expected Outcome

• Flyway validation should ignore checksum differences for migrations that are already applied and successful, when configured to do so, so the service does not fail on startup because of local file edits that change checksums.
• The solution should be configurable (property/flag) and clearly documented so teams can enable it only in non-production contexts or developer environments.

---

Acceptance Criteria

• Given a migration row in flyway_schema_history with success = true, changing the corresponding migration file checksum locally and restarting the service should not cause Flyway validation failures when the new configuration flag is enabled.
• The behaviour must be toggleable via configuration (e.g., Spring profile, environment variable or Flyway property) and documented.
• Production deployments (by default) must keep strict validation enabled.

---

Implementation Details

Proposal

1. Add a configurable Flyway validation rule that ignores migrations matching an "already-applied" pattern. Investigate using Flyway's ignoreMigrationPatterns (or equivalent) to skip checksum validation for applied migrations — see Redgate blog reference above.
2. Expose a Spring Boot property (e.g. amrit.flyway.ignore-applied-migration-checksum=true/false) that, when enabled in non-production profiles, configures Flyway to ignore checksum mismatches for migrations that are already applied.
3. Ensure the property is false by default. Wire the property to be enabled in local / developer profiles only (e.g., application-local.yml, or via an env var AMRIT_FLYWAY_IGNORE_APPLIED=true used in developer docker-compose).

Tech notes

• Repo: https://github.com/PSMRI/AMRIT-DB
• Tech stack: Java, Spring Boot, Flyway, Docker (local dev)
• Candidate Flyway mechanisms: ignoreMigrationPatterns, custom ValidationStrategy, or configuring flyway.validateMigrationNaming / flyway.baselineOnMigrate depending on Flyway version.
• Make sure changes only affect validation behavior, not the recorded flyway_schema_history entries.

---

Mockups/Wireframes

Not applicable.

---

How to Test (manual steps)

1. Run AMRIT-DB locally (or dev environment) so Flyway applies all migrations successfully.
2. Confirm a migration row is present in flyway_schema_history with success = true and note the checksum value.
3. Modify the checksum value in the flyway_schema_history table (to simulate a changed file checksum) OR change the migration file contents locally which would alter checksum on next run.
4. Restart the AMRIT-DB service and observe that, without the change, Flyway reports checksum validation errors and service startup fails.
5. Enable the new configuration (e.g., set AMRIT_FLYWAY_IGNORE_APPLIED=true or use the local Spring profile) and restart the service.
6. Confirm the service starts successfully and Flyway does not fail on the checksum mismatch for the already-applied migration.

Repro steps summary: Run AMRIT-DB, apply migrations, change checksum in flyway_schema_history table, rerun service and observe checksum error. After enabling the new config, the error should not occur.

---

Tech Skills Needed

• Database
• MySQL
• Java
• Spring Boot
• CI/CD / DevOps

---

Organizational Mentor

@drtechie

---

Complexity

• Medium

---

Category

• Backend
• Database
• CI/CD
• Maintenance

[saurabh24thakur]

I want to work on this issue please assign this to me

[drtechie]

Hi @saurabh24thakur any updates? Have you figured how to accomplish this?

[saurabh24thakur]

Hi @drtechie, thank you for the assignment. Yes, I have been researching the Flyway configuration to handle this.

My Plan:

I am focusing on using the flyway.ignoreMigrationPatterns property as suggested in the documentation you shared. Specifically, I plan to use the pattern :applied to ignore checksum mismatches for already-applied migrations.

I will implement a Spring Boot property amrit.flyway.ignore-applied-migration-checksum (defaulting to false) to toggle this behavior.

I am currently setting up the AMRIT-DB repository locally to reproduce the checksum error by manually editing a migration file content after its initial successful run.

I will raise a draft PR once I verify the toggle works correctly across different Spring profiles (local vs. default). I expect to share the PR by today evening."

[drtechie]

Alright. Sounds good. Thanks for the update. We are planning a production deployment on Monday. It will be great if you can raise the PR before that.