In our team, we do regular upgrade of our library versions as a housekeeping chores. Last week, we had to halt our phased roll out and had to revert back to an older version due to a production bug we introduced in one of our feature. However, after releasing the reverted version, we started to see crashes happening for users who already received the update with newer Tealium version.
These crashes happens because the newer version uses Tealium 1.5.0+ where as the rolled back version still has Tealium 1.4.3. I believe database upgrade was added back in 1.5.0 but since the previous library versions didn't implement onDowngrade, the app started crashing when it tries to downgrade back to database version 1.
We were able to patch this by making a hotfix with just changes made to upgrade to Tealium 1.5.0 but however since some of are users are already affected by this and since it crashes on launch, there was no way for us to inform these users to update again to latest version. I believe a proper fix would be to implement onDowngrade going forward.
Problem Statement
Since no downgrade for database is implemented, every time tealium update database version, there is no simple way1 for consumers to downgrade back to previous tealium version.
In the future, this could leads to major issue if tealium introduces a critical bug and apps need to downgrade back to older version as part of mitigation strategy. For example,
Tealium version 1.6 updates database version.
Users update tealium version to 1.6.
Users made a release on Play Store
After a week later, the critical vulnerability is discovered,
While the devs are working on patch in 1.6.1, users were advised to downgrade back to 1.5.
Doing so would lead to hard crash on launch.
1 : You can force delete data/tealium folder before doing anything else in Application's onCreate.
Steps to reproduce
Build & Run the app with Tealium 1.5.0 and forward
Downgrade tealium back to 1.4.3
Observe crash on launch
Fix
In ideal scenario, we would want to revert only the upgrade we made but that would be near impsossible to do since we would need to do what we're upgrading a version ahead of time. For now, We could use destructive migration. The app might loses previously saved data but I think it's better than hard crashing on launch. (See: #217)
In our team, we do regular upgrade of our library versions as a housekeeping chores. Last week, we had to halt our phased roll out and had to revert back to an older version due to a production bug we introduced in one of our feature. However, after releasing the reverted version, we started to see crashes happening for users who already received the update with newer Tealium version.
These crashes happens because the newer version uses Tealium
1.5.0+where as the rolled back version still has Tealium1.4.3. I believe database upgrade was added back in 1.5.0 but since the previous library versions didn't implementonDowngrade, the app started crashing when it tries to downgrade back to database version 1.We were able to patch this by making a hotfix with just changes made to upgrade to Tealium 1.5.0 but however since some of are users are already affected by this and since it crashes on launch, there was no way for us to inform these users to update again to latest version. I believe a proper fix would be to implement
onDowngradegoing forward.Problem Statement
Since no downgrade for database is implemented, every time tealium update database version, there is no simple way1 for consumers to downgrade back to previous tealium version.
In the future, this could leads to major issue if tealium introduces a critical bug and apps need to downgrade back to older version as part of mitigation strategy. For example,
1.6updates database version.1.6.1.6.1, users were advised to downgrade back to1.5.1 : You can force delete
data/tealiumfolder before doing anything else in Application's onCreate.Steps to reproduce
1.5.0and forward1.4.3Fix
In ideal scenario, we would want to revert only the upgrade we made but that would be near impsossible to do since we would need to do what we're upgrading a version ahead of time. For now, We could use destructive migration. The app might loses previously saved data but I think it's better than hard crashing on launch. (See: #217)