From 87eb72ff19265fdfe9d8862889d433dce95ca4ea Mon Sep 17 00:00:00 2001
From: Subhra264 <chakrabortysubhradeep556@gmail.com>
Date: Tue, 21 Jan 2025 19:04:22 +0530
Subject: [PATCH] fix: run upto the populate_alerts_table migration first
 (#5755)

This is a hack to fix #5740 . As mentioned in
https://github.com/openobserve/openobserve/pull/5752, with postgresql
there is an issue when upgrading from v0.14.0 to v0.14.1 or v0.14.2 -
The migration `m20250109_092400_recreate_tables_with_ksuids` fails with
an error message. So after testing, it looks like the earlier mentioned
migration requires the `m20241209_120000_create_alerts_table` migration
to be committed to db first (so upto
`m20241217_155000_populate_alerts_table` migration).

Earlier https://github.com/openobserve/openobserve/pull/5722 was used to
address the issue, but unfortunately it works when upgrading from below
`v0.14.0` to `v0.14.2`. Currently the way to upgrade to v0.14.2 from
v0.14.0 with postgresql is to first upgrade from `v0.14.0` to
`v0.14.1-rc1` and then to `v0.14.2`.

This PR should make the direct upgrade from v0.14.0 to v0.14.3 possible
with postgresql.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Bug Fixes**
- Improved migration process for alerts table to ensure correct index
selection and prevent potential migration failures.

- **Documentation**
- Enhanced comments to provide clearer context about migration logic and
order of execution.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---
 src/infra/src/table/mod.rs | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/src/infra/src/table/mod.rs b/src/infra/src/table/mod.rs
index 18b6a08d89..beb7176447 100644
--- a/src/infra/src/table/mod.rs
+++ b/src/infra/src/table/mod.rs
@@ -42,12 +42,36 @@ pub async fn init() -> Result<(), anyhow::Error> {
 pub async fn migrate() -> Result<(), anyhow::Error> {
     let locker = dist_lock::lock("/database/migration", 0).await?;
     let client = ORM_CLIENT.get_or_init(connect_to_orm).await;
-    Migrator::up(client, Some(12)).await?; // hack for failing alerts migration
+    // This is a hack to fix the failing alerts migration
+    // For postgres, we need to run the migration that populates the alerts table first.
+    // Otherwise, the `m20250109_092400_recreate_tables_with_ksuids` migration will fail.
+    let first_stage = get_alerts_populate_migration_index().await?;
+    Migrator::up(client, Some(first_stage)).await?; // hack for failing alerts migration
     Migrator::up(client, None).await?;
     dist_lock::unlock(&locker).await?;
     Ok(())
 }
 
+/// Get the index of the migration that populates the alerts table.
+/// This index is used as the first stage of the migration process.
+async fn get_alerts_populate_migration_index() -> Result<u32, anyhow::Error> {
+    let client = ORM_CLIENT.get_or_init(connect_to_orm).await;
+    let migrations = Migrator::get_pending_migrations(client).await?;
+    let mut index: u32 = 0;
+    for (i, migration) in migrations.iter().enumerate() {
+        if migration.name() == "m20241217_155000_populate_alerts_table" {
+            index = i as u32 + 1;
+            break;
+        }
+    }
+    // If the migration is not found, it is already applied so return 0
+    log::debug!(
+        "Migration m20241217_155000_populate_alerts_table at step {} (0 means already applied)",
+        index
+    );
+    Ok(index)
+}
+
 pub async fn down(steps: Option<u32>) -> Result<(), anyhow::Error> {
     let client = ORM_CLIENT.get_or_init(connect_to_orm).await;
     Migrator::down(client, steps).await?;