Continuing migration from v42 to v43, I’ve hit a warning on 2.43.1 which I’d like a second opinion on it. I’ve filed it as Jira, but I’m posting here because I suspect a lot of installations are quietly logging this.
Analytics requests touching certain enrollment-type program indicators fill the log with:
WARN org.hisp.dhis.analytics.event.data.programindicator.BoundarySqlBuilder [http-nio-8080-exec-7]
Unsupported boundary type BEFORE_END_OF_REPORTING_PERIOD for PI <uid>
To reproduce, it takes two things together, and neither alone is enough.
1. A period boundary whose target is a data element rather than EVENT_DATE:
That’s the usual way to express “total ever registered as of the end of the period”, with the data element holding the initial visit date. 2. A filter that references an event-level item. This is the part I got wrong at first. It isn’t about any single variable:
Enrollment-scoped filters and constants stay silent. Anything that forces the filter down to event level triggers it. Worth stressing that this issue is different from other bug reported at V{event_status} in enrollment program indicator filters breaks analytics in 2.43.1 and this one actually works as expected and returns correct output and the reason I’m raising it is I don’t know whether:
The warning is simply inaccurate.BoundarySqlBuilder isn’t the component handling this case and the message is misleading noise. Annoying, harmless, a logging fix.
OR
The boundary is surviving on a fallback path, and the new CTE-based builder genuinely doesn’t support a data-element boundary target when it has to build event-level filter SQL. In that case these indicators start returning wrong numbers silently the day the old path is retired.
The second scenario is what worries me. “Total registered as of period end” quietly becoming “total registered ever” is the kind of regression that survives a long time in a national dashboard, because the number still looks perfectly reasonable.
Questions
Is this warning benign, or does it mark a deprecated path?
If it’s the latter, what’s the supported way on 2.43+ to express a data-element-targeted period boundary on an enrollment indicator that also has an event-level filter?
Thanks for the detailed investigation. Based on the behavior you described, I would suggest first treating this as an Analytics/Program Indicator implementation issue rather than a configuration problem.
For the immediate workaround, if the objective is to use a date stored in a program-stage data element as the enrollment boundary, you could move the period comparison into the Program Indicator filter using d2:daysBetween() and V{analytics_period_end} instead of relying on the custom boundary.
This should allow the indicator to explicitly evaluate the data-element date against the reporting period.
However, I would recommend keeping the Jira issue open because the warning itself is still significant. In particular, it would be important to confirm whether BoundarySqlBuilder is simply logging an incorrect warning or whether the data-element boundary is actually being ignored when the query is pushed to the event level.
I would also compare the results between 2.42 and 2.43.1 using the same indicator and several reporting periods. If the figures remain identical, the warning may be harmless logging noise; if they differ, it could indicate a regression in the new analytics path.
So, for production, I would not remove or change the boundary blindly until the calculation has been validated.
Many thanks for your reply, I can confirm that the proposed method works fine in 2.43 and doesn’t result in any warning in logs. So, the remaining question from dev team is the first question in my original post:
Is this warning benign, or does it mark a deprecated path? Should we start migrating to d2:daysBetween() from the current analyticsPeriodBoundaryType approach?
Your configuration looks supported according to the documentation. For enrollment analytics, a custom boundary can target a date data element using #{programStageUid.dataElementUid}, so I wouldn’t interpret the warning alone as evidence that this configuration has been deprecated.
The interesting part is that it only appears once the filter requires event-level SQL, while the result is still correct. That does make this look like either a misleading warning from the new SQL-building path or a case where another/fallback path is still applying the boundary correctly.
One test that would settle it directly: construct an enrollment where DaTeElEm001 falls outside the reporting period but still has an event satisfying your event-level filter. If that enrollment is excluded, the boundary is still being enforced and this is just a mislabeled warning. If it’s included, the boundary is being dropped on this path and you have concrete proof for the ticket rather than just the reproduction table.
Since you’ve already isolated the trigger clearly and raised DHIS2-22072, I’d attach that edge case result to the ticket and let the core team confirm from there. Until then I wouldn’t change the indicator configuration, since the documented approach is still the one you’re using.
Hi @e4eDHIS2, in your suggested test, that enrollment is excluded. And yes, we’ve stopped migration to v43 for now rather than changing indicator configurations.