Add Flyway repair strategy for duplicate V14 migration checksum mismatch

[Copilot]

Two migrations exist with version V14 (V14__create_usda_food_tables.sql and V14__seed_default_api_key.sql), causing Flyway checksum validation failures on startup.

Changes

• Added temporary FlywayMigrationStrategy bean to FitnessAppApplication.java that repairs the schema history table before running migrations
• Created FLYWAY_REPAIR_INSTRUCTIONS.md with removal instructions after successful startup

@Bean
public FlywayMigrationStrategy repairStrategy() {
    return flyway -> {
        flyway.repair();  // Fix checksum mismatches
        flyway.migrate(); // Apply pending migrations
    };
}

Post-Deployment

This bean is a one-time fix and must be removed after the application starts successfully. The repair operation updates checksums in flyway_schema_history without touching application data.

Root Cause

Flyway requires unique version numbers for each migration. The duplicate V14 versions should be renamed (e.g., one to V16) in a future migration cleanup.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>fix the data migration</issue_title>
<issue_description>You lack database tools, don't want to manually modify the database, and absolutely cannot delete the database and lose data.

Great, let's solve this using a programmer's approach—write code to fix it!

Flyway has a dedicated command called Repair.

Its function is to **only repair the "ledger" (flyway_schema_history), absolutely avoiding your business data (users, food_logs). It will recalculate the checksums of all your files and update the database, settling the mess.

Since you have a Spring Boot project, we can directly inject a "repair strategy" into the startup class, allowing the app to automatically perform a repair once upon startup.

⚡️ Ultimate Data Recovery Method: Java Code Injection

Please strictly follow these 3 steps:

Step 1: Modify the Startup Class

Open your backend main class FitnessAppApplication.java (located in backend/src/main/java/.../FitnessAppApplication.java).

Below the main method, paste this @Bean code:

``java
import org.springframework.boot.autoconfigure.flyway.FlywayMigrationStrategy;
import org.springframework.context.annotation.Bean;

// ... Your other imports and annotations ...

@SpringBootApplication
public class FitnessAppApplication {

public static void main(String[] args) {

SpringApplication.run(FitnessAppApplication.class, args);

}

// ========== Copy the following section ==========

@bean

public FlywayMigrationStrategy repairStrategy() {

return flyway -> {

// This line is key: repair the ledger first, then migrate

flyway.repair();

flyway.migrate();

};

}

// ====================================

}

#### Step 2: Start the Backend

Return to the terminal and run again:

```bash

./gradlew bootRun

What will happen at this point:

1. Spring Boot starts.

2. A custom Flyway strategy is detected.

3. flyway.repair() is executed — at this point, the V14 record with the mismatched checksum in the database will be automatically corrected to a new checksum (or marked for repair).

4. flyway.migrate() is executed — continuing to execute subsequent V15, V16...

5. The console should display a green Started FitnessAppApplication! **

Step 3: Dismantle the Bridge After Crossing the River (Important!)

Once the backend starts successfully, the ledger is fixed.

Immediately delete the @Bean code you just added!

Why? Because you don't want to repair it every time you start the system. While harmless, it's unnecessary.

-----</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes fix the data migration #48

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.