For those that know me… hi… it’s been a while. I migrated back to my home country (NZ) late last year and am re-engaging with the DHIS2 community. Seems like a whole lot of good stuff has happened over the last couple of years.
I have a specific support question related to data-entry forms not loading when going into the standard interface after an upgrade from V2.34.2 from 2.33.6 on a training environment (not the production environment). It’s still important as I will have to revert back a version if we can’t resolve this in the next 24 hours as training is about to be delivered.
Note that we had one one custom form upgrade error during the update process (which we have taken out of the picture for the moment by removing). Also note that there was an identical query back in May from a user that remains ananswered (message on 27 May).
Here’s the issue capture in the following screenshot:
The getMetaData.action call returns an exception, and causes a parse issue in the user interface shown in the screenshot (the Data Set forms list don’t load).
While the screenshot displays “No Organisation Unit Selected - No Period Selected - No Data Element Selected”, an organisation is indeed selected, with the setorgunit.action call returning a status code of 200 and a proper json response
The backend error is a chain very similar to the mentioned email above, and starts with:
2020-11-17T09:27:18,428 Error while executing action (ExceptionInterceptor.java [qtp1588970020-83061])
java.lang.NumberFormatException: null
at java.math.BigDecimal.(BigDecimal.java:497) ~[?:1.8.0_221]
at java.math.BigDecimal.(BigDecimal.java:383) ~[?:1.8.0_221]
at java.math.BigDecimal.(BigDecimal.java:809) ~[?:1.8.0_221]
at java.math.BigDecimal.valueOf(BigDecimal.java:1277) ~[?:1.8.0_221]
and seems to head down this pather before going into java library land…
at org.hisp.dhis.expression.DefaultExpressionService.getExpressionOrgUnitGroups(DefaultExpressionService.java:488) ~[dhis-service-core-2.34.2.jar:?]
at org.hisp.dhis.expression.DefaultExpressionService.getIndicatorOrgUnitGroups(DefaultExpressionService.java:275) ~[dhis-service-core-2.34.2.jar:?]
at org.hisp.dhis.expression.DefaultExpressionService.substituteIndicatorExpressions(DefaultExpressionService.java:334) ~[dhis-service-core-2.34.2.jar:?]
at sun.reflect.GeneratedMethodAccessor2930.invoke(Unknown Source) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_221]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_221]…
I have done the following to try and eliminate any potential form/indicator metadata issues:
Set all data sets to ‘Skip Download’
Eliminated stray carriage returns from the numerators/denominators of all indicators
The problem still exists however.
Any other hints on where to go next would be appreciated.
We’re having a similar issue with the same error after upgrading to 2.34 in a test environment . My plan is to review the OUs in the database and see if I can find any blatant missing information which may be causing the error. Have you had any luck getting past this?
We get the error you do…
Error while executing action (ExceptionInterceptor.java [xxx])
java.lang.NumberFormatException: null
at java.math.BigDecimal.(BigDecimal.java:497) ~[?:1.8.0_221]
at java.math.BigDecimal.(BigDecimal.java:383) ~[?:1.8.0_221]
at java.math.BigDecimal.(BigDecimal.java:809) ~[?:1.8.0_221]
at java.math.BigDecimal.valueOf(BigDecimal.java:1277) ~[?:1.8.0_221]
which is immediately preceded by this query:
select ou.uid as ou_uid,
array_agg(ds.uid) as ds_uid
from datasetsource d
inner join organisationunit ou on ou.organisationunitid=d.sourceid
inner join dataset ds on ds.datasetid=d.datasetid
where (ou.path like ‘/ybg3MO3hcf4%’ ) group by ou_uid;
That query doesn’t seem to cause an error and when executed in pgAgmin4 seems to produce output without issue.
I think we’re going to have to revert back to 2.33 if we can’t get past this.
So, the team was actually working on this in the last days and they have a solution. It is tracked here. The fix will be ported to affected versions (2.34 and 2.35) and available in the next patches following successful testing. Note: The target release date for 2.34.3 is the end of next week and we plan to include this!
Please note for everyone watching this thread that I resolved the error by identifying a specific Indicator amongst the thousands that was an ‘invalid indicator’. Removal of this indicator and the custom form it was on resolved the issue. I am not certain the ‘fix’ you’ve suggested would have covered this as it is not a ‘timing’ issue, but the fact that ‘nothing comes back’ when an invalid indicator is part of the metadata package (i.e. the error is raised).
Yes, I identified an invalid indicator that was included in one of the forms. Removing and deleting the indicator allowed the metadata-expansion routine to complete and thus the rendering of the loading of the forms on the front-end.
I should also point out that in addition to the indicator expansion problem, there is also a linked bug with the ANTLR division parsing. We believe the combination is the likely cause of people seeing this issue following upgrades.
