DHIS2 version 2.36.2 is now released as a HOT FIX patch.
This HOT FIX addresses an issue that can affect the API used for synchronising data from Android and other external clients. It does not include additional bug fixes or enhancements.
The issue is present in DHIS versions 2.36.0 and 2.36.1.
If your implementation is running an affected version of DHIS2 you may be at risk of data loss due to failed synchronisation.
Your implementation might be affected if you are using the DHIS2 Android App [1] or any custom client using the trackedEntityInstance WebAPI endpoint and any of these conditions are met:
You have any users that do not have access to search for tracked entity instances across all org units (search scope not set at root level)
Any of your tracker programs are configured with the “Access level” set to either “Protected” or “Closed”
If you think you might be affected please send a message directly to @dhis2-tracker (<-- click the name and select message) and we can assist in avoiding the loss of any unsynchronised data.
[1] Note: Data is safe in the mobile device, but if that data is deleted from the device, because there is a change of user or the user manually deletes it before it can be synchronised, then the data will be lost. This HOT FIX patch will fix future synchronisation, and a HOT FIX for the Android Capture app will add a feature to facilitate re-synchronisation of previous changes on devices.
As usual, this is the latest stable release for version 2.36, and supersedes releases 2.36.0 to 2.36.1.
The release note for this patch can be found here: Patch 2.36.2 Release Note
I am trying to upgrade 2.36.1 to 2.36.2 and I am getting the following error:
ERROR 2021-07-02T09:31:23,860 Context initialization failed (ContextLoader.java [main])
org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘webMvcConfig’: Unsatisfied dependency expressed through field ‘userSettingService’; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘org.hisp.dhis.user.UserSettingService’ defined in URL [jar:file:/home/dhis/tomcat-dhis/webapps/dhis/WEB-INF/lib/dhis-service-core-2.36.2.jar!/org/hisp/dhis/user/DefaultUserSettingService.class]: Unsatisfied dependency expressed through constructor parameter 2; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name ‘org.hisp.dhis.user.UserSettingStore’ defined in URL [jar:file:/home/dhis/tomcat-dhis/webapps/dhis/WEB-INF/lib/dhis-service-core-2.36.2.jar!/org/hisp/dhis/user/hibernate/HibernateUserSettingStore.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name ‘flyway’ defined in class path resource [org/hisp/dhis/db/migration/config/FlywayConfig.class]: Invocation of init method failed; nested exception is org.flywaydb.core.api.FlywayException: Validate failed:
Detected applied migration not resolved locally: 2.36.37. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.38. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.39. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.40. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.41. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.42. If you removed this migration intentionally, run repair to mark the migration as deleted.
Detected applied migration not resolved locally: 2.36.43. If you removed this migration intentionally, run repair to mark the migration as deleted.
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredFieldElement.inject(AutowiredAnnotationBeanPostProcessor.java:643) ~[spring-beans-5.3.2.jar:5.3.2]
Please do not delete the flyway table. That is not a solution.
The flyway schema history table is internal and its needed by flyway to track the changes of the schema and verify consistency of the database.
Every error that flyway throws will have a reason, and its important to find the reason rather then trying to delete the table and lose precious info on why flyway threw an error in the first place. Its more likely to end up in an inconsistent state and all future flyway migrations will have issues if you delete or modify the flyway_schema_history table without understanding the root cause of the issue.
@waviles I would like to repeat not to delete flyway table at any cost. But I assume you have already done it. Hoping its not a production database. Deleting the flyway table will have more consequences in future.
This error indicates that you tried to deploy 2.36-SNAPSHOT at some point onto this specific database. Which means your db has got migrations well into the development versions of 2.36 (which are to be released in 2.36.3 patch version or so), and these migrations are not released as part of the 2.36.2 patch release.
It basically means you tried to downgrade from a “higher” version to a “lower version” of dhis2. If this is only a test instance, then simply removing the specific rows for the “versions” mentioned in the error will fix it. Not the entire table . Example: delete from flyway_schema_history where version=‘2.36.37’.
Thanks so much for the advice, it is indeed a development instance, and what I did was to restore the DB to the 2.36.1 backup. I think the root cause was that we had the development unreleased version of the war file (2.36.1), after installing the 2.36.1 release, the 2.36.2 patch upgrade completed with no issues.
I don’t understand why deleting it shouldn’t be an issue. When the system is restarted the table is automatically created again and the system is restored to normal.
@Gerald_Thomas Not sure how I can emphasize further that deleting the flyway table is an issue. Deleting the flyway schema history table is a very big issue .
All history is lost. When the system restarts, it only knows what migrations are packaged in the war, it does not know what are the migrations that have been previously applied on the database. Flyway retries all migrations and recreates the table on a best effort based on what migrations are packaged in the war, but we lose all the historical data of what migrations have previously been applied on the database which is a very big issue.
Some parts of the dhis2 application will not work as expected if there is an incompatibility in the database with the dhis2 version, but you will only realize it very late when a user is using that part of the system. Even though the application starts fine (after deleting the flyway table), doesnt mean everything is perfect.
Dear Ameen,
Thanks for the corrections… I already look at it again and had further discussion on this topic with System Administrators. Sorry, I initially said we should delete the flyway table which shouldn’t be the case, rather this query should be run on the Postgres database: select * from flyway_schema_history order by installed_rank desc;
This will list the rows in the flyway table and those with issues will show “f” on the “success” column Note “f” is for failed transactions
It is those rows that need to be deleted and restart the tomcat or the server.
@Gerald_Thomas Yes, that is what I have suggested to William in this same thread above. DHIS2 patch release 2.36.2 is now available - [HOT FIX] - #10 by Ameen
Once again, it is still worth to know why it failed in the first place when trying to clear these specific rows. Removing the specific rows should only be done if its clear what the issue is, and if it doesnt impact the stability of the db,
Hi @Ameen Can we also do this for the production environment also? It worked in our case, but does it have any impact since it’s production environment?