In versions 1.3.x and earlier, the time formatting stored in the database was inconsistent with time.RFC3339 used in some places and time.RFC3339Nano used in others.
In v1.4.0, this inconsistency was removed by using time.RFC3339Nano everywhere. The duration key was also updated to report nanoseconds instead of minutes:
Due to these changes, a migration was added so that when users of v1.3.x upgraded, the old format will be translated to the new one seamlessly. However, the migration logic was flawed leading to it being run for subsequent versions (like v1.4.1). The result was data loss.
The solution is to ensure the migration is ran only when upgrading to v1.4.0.
In versions 1.3.x and earlier, the time formatting stored in the database was inconsistent with
time.RFC3339used in some places andtime.RFC3339Nanoused in others.In v1.4.0, this inconsistency was removed by using
time.RFC3339Nanoeverywhere. Thedurationkey was also updated to report nanoseconds instead of minutes:Due to these changes, a migration was added so that when users of v1.3.x upgraded, the old format will be translated to the new one seamlessly. However, the migration logic was flawed leading to it being run for subsequent versions (like v1.4.1). The result was data loss.
The solution is to ensure the migration is ran only when upgrading to v1.4.0.