Schema check fails if schema upgrade applied more than once

[alamp1360]

I tried to run the newest version of IcingaDB and got the following error:

Starting Icinga DB daemon (1.5.1-g6400506)
2026-02-02T13:49:58.175+0100    INFO    icingadb        Connecting to database at 'mysql://icingadb@mariadb-test:3306/icingadb'
2026-02-02T13:49:58.178+0100    FATAL   icingadb        unexpected database schema version: incomplete database schema upgrade: intermediate version v6 is missing, please make sure you have applied all database migrations after upgrading Icinga DB

When checking the icingadb_schema table, i see the following:

MariaDB [icingadb]> select * from icingadb_schema;
+----+---------+---------------+
| id | version | timestamp     |
+----+---------+---------------+
|  1 |       4 | 1712212035000 |
|  2 |       5 | 1731611374000 |
|  3 |       6 | 1731611374000 |
|  4 |       5 | 1731612537000 |
|  5 |       6 | 1731612537000 |
|  6 |       6 | 1746607904000 |
|  7 |       7 | 1751438713000 |
+----+---------+---------------+

Dont ask me how this happened, but the following code in file schema.go (line 73ff) in dir pkg/icingadb cannot deal with it:

	// Check if each schema update between the initial import and the latest version was applied or, in other words,
	// that no schema update was left out. The loop goes over the ascending sorted array of schema versions, verifying
	// that each element's successor is the increment of this version, ensuring no gaps in between.
	for i := 0; i < len(versions)-1; i++ {
		if versions[i] != versions[i+1]-1 {
			return fmt.Errorf(
				"%w: incomplete database schema upgrade: intermediate version v%d is missing,"+
					" please make sure you have applied all database migrations after upgrading Icinga DB",
				ErrSchemaMismatch, versions[i]+1)
		}
	}

I was able to fix the issue by removing the duplicate entries manually, but i guess the actual behaviour could be seen as a minor bug, so i wanted to bring it to your attention...

[oxzi]

First, thanks a lot for testing an unstable Icinga DB release. This kind of feedback is very welcome!

This change was introduced in #789 and was intended to abort a start when no clean schema upgrade history can be detected. In the past, users applied schema upgrades in a confusing order, resulting in a messy schema. Instead of letting Icinga DB crash after a certain time, we decided it would be better to not start under such undefined situations at all.

As you went from version six back to version five and then to version six again, twice, this check is now failing. So, I would kindly ask you to verify if your schema matches the expected one and to clean up the icingadb_schema entries afterwards. And, thanks again for testing and reporting.

[alamp1360]

Thanks for the clarification. As i stated in my initial post, i cleaned up the icingadb_schema table by deleting the duplicate entries.
But i have still no clue how i managed to get into that mess...

I am using icingadb as provided by the "official" docker image and, over the years, did schema updates manually when it was neccessary. Are there any automatic schema updates taking place?

[oxzi]

As you are using the latest and unreleased version, I can only think of conflicting changes in the schema upgrade files between releases. However, I cannot remember decreasing the schema version number, as this would be breaking and does not make much sense.

There is no automatic schema upgrading mechanism at the moment as this would still be destructive. If you are interested in details, take a look at #1061 and the PRs referred there.

[oxzi]

After talking about this issue internally, I am going reopen it and change the logic to be not sooo strict anymore. Thanks again for reporting.