[jira] [Commented] (FINERACT-2865) Reading a group's calendars fails with HTTP 500 when it has a non-repeating calendar

["Foo Developer (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/FINERACT-2865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120315#comment-18120315 ] 

Foo Developer commented on FINERACT-2865:
-----------------------------------------

Small correction to the Expected section: with the fix, a non-repeating calendar reads back with {{repeating: false}}, {{interval: 0}} and no {{frequency}} / {{repeatsOnDay}}, but {{repeatsOnNthDayOfMonth}} is returned as {{nthDayType.invalid}} rather than being absent. The PR description and its unit test reflect this actual behaviour.

> Reading a group's calendars fails with HTTP 500 when it has a non-repeating calendar
> ------------------------------------------------------------------------------------
>
>                 Key: FINERACT-2865
>                 URL: https://issues.apache.org/jira/browse/FINERACT-2865
>             Project: Apache Fineract
>          Issue Type: Bug
>          Components: Groups
>            Reporter: Foo Developer
>            Assignee: Foo Developer
>            Priority: Major
>
> h3. Summary
> Reading calendars fails with a {{NullPointerException}} as soon as the entity has a *non-repeating* calendar. A non-repeating calendar is stored with {{recurrence = NULL}} (by design, see {{Calendar}} constructor and {{Calendar.update}}), but the row mappers in {{CalendarReadPlatformServiceImpl}} pass that null rule straight into {{CalendarUtils}}, which hands it to ical4j's {{RRule}} parser.
> h3. Steps to reproduce (stock Fineract)
> # Create a group: {{POST /v1/groups}} (any office, active).
> # Add a non-repeating, non-collection calendar to it:
> {code:json}POST /v1/groups/{groupId}/calendars
> { "title": "One-off meeting", "typeId": 4, "repeating": false, "startDate": "28 September 2026", "locale": "en", "dateFormat": "dd MMMM yyyy" }
> {code}
> # Read it back: {{GET /v1/groups/{groupId}/calendars/{calendarId}}}, or list {{GET /v1/groups/{groupId}/calendars}}. The same mapper also backs other calendar reads, e.g. {{GET /v1/loans/template?templateType=jlgbulk&groupId={groupId}}}.
> h3. Expected
> HTTP 200. The calendar is returned with {{repeating: false}}, no {{frequency}} / {{repeatsOnDay}} / {{repeatsOnNthDayOfMonth}} and {{interval: 0}}, the same defaults already used for a rule that cannot be parsed.
> h3. Actual
> The request fails with HTTP 500 ({{Internal Server Error}}); the server log shows a {{NullPointerException}} ({{Cannot invoke "String.split(String)" because "aValue" is null}}) thrown from {{CalendarUtils.getICalRecur}} (ical4j {{RRule}} with a null rule string), reached from {{CalendarReadPlatformServiceImpl$CalendarDataMapper.mapRow}}.
> h3. Root cause
> Both {{CalendarDataMapper}} and {{CalendarDataFromHistoryMapper}} call {{CalendarUtils.getFrequency}}, {{getInterval}}, {{getRepeatsOnDay}}, {{getRepeatsOnNthDayOfMonth}} and {{getMonthOnDay}} unconditionally. Each of them parses the rule with {{getICalRecur(recurrence)}}, which cannot handle {{null}}. The neighbouring {{humanReadable}} computation in the same mappers already guards with {{recurrence != null}}; the other five calls do not.
> h3. Proposed fix
> Guard those five calls with {{recurrence != null}} in both mappers and fall back to {{CalendarFrequencyType.INVALID}}, {{0}}, {{CalendarWeekDaysType.INVALID}}, {{NthDayType.INVALID}} and {{null}} (which {{CalendarEnumerations}} already renders as "no value"). Repeating calendars are unaffected.
> h3. Test
> A unit test {{CalendarReadPlatformServiceImplTest}} maps a non-repeating calendar row (null recurrence) through {{retrieveCalendar}} and checks the defaults, plus a repeating row to show the rule is still parsed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)