starred/openobserve
1
0
Fork 0
mirror of https://github.com/openobserve/openobserve.git synced 2026-11-05 08:09:22 +00:00
Code Issues Packages Projects Releases Wiki Activity

fix: run upto the populate_alerts_table migration first (#5755)

Browse Source 
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 -->
This commit is contained in:
Subhra264
2025-01-21 19:04:22 +05:30
committed by GitHub
parent 311153e89e
commit 87eb72ff19
1 changed files with 25 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/infra/src/table/mod.rs
+25 -1
View File
@@ -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?;