/api/notifications/all fails for user with large notification volume (e.g., dataverseAdmin)

[ofahimIQSS]

Bug Report: /api/notifications/all fails for user with large notification volume

Environment

• Branch: develop (latest as of July 2025)
• User: dataverseAdmin (has thousands of notifications)
• Tested during: PR testing for #11664
• API Call:

  curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all"
  

Bug Description
The /api/notifications/all endpoint fails when invoked by a user who has a very large volume of notifications. This issue was discovered while testing PR #11664, but it exists in the develop branch independently of that PR.

Steps to Reproduce
Log in as a superuser or admin account with thousands of notifications (e.g., dataverseAdmin)

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all"
Observe that the API call fails (e.g., no response or internal server error)

Expected Behavior
The API call should return the user's notifications, or at least respond with a subset (paginated or filtered), without crashing or timing out.

Actual Behavior
The request fails entirely

**

11664 server.log

**
Relevant stack trace is available in the server.log from internal testing.

Notes
This is not a regression introduced by PR #11664

Suggested Fix
Add pagination support to /api/notifications/all
Add filtering options (e.g., ?type=..., ?since=...)
Enforce maximum limits and document default behavior for large volumes

[pdurbin]

In the stackstrace, @ofahimIQSS and I were wondering what "far" is:

Caused by: java.lang.NullPointerException: Cannot invoke "edu.harvard.iq.dataverse.FileAccessRequest.getGuestbookResponse()" because "far" is null at edu.harvard.iq.dataverse.MailServiceBean.getMessageTextBasedOnNotification(MailServiceBean.java:457)

It turns out it's this part of the code:

case REQUESTFILEACCESS:
    //Notification to those who can grant file access requests on a dataset when a user makes a request
    DataFile datafile = (DataFile) targetObject;

    pattern = BundleUtil.getStringFromBundle("notification.email.requestFileAccess");
    String requestorName = (requestor.getLastName() != null && requestor.getLastName() != null) ? requestor.getFirstName() + " " + requestor.getLastName() : BundleUtil.getStringFromBundle("notification.email.info.unavailable");
    String requestorEmail = requestor.getEmail() != null ? requestor.getEmail() : BundleUtil.getStringFromBundle("notification.email.info.unavailable"); 
    String[] paramArrayRequestFileAccess = {datafile.getOwner().getDisplayName(), requestorName, requestorEmail, getDatasetManageFileAccessLink(datafile)};
    messageText = BundleUtil.getStringFromBundle("notification.email.greeting.html");
    messageText += MessageFormat.format(pattern, paramArrayRequestFileAccess);
    FileAccessRequest far = datafile.getAccessRequestForAssignee(requestor);
    GuestbookResponse gbr = far.getGuestbookResponse();

So it may be something with this user's account in particular rather than the sheer volume of messages.

[qqmyers]

@ofahimIQSS - which machine?

[pdurbin]

@qqmyers internal

[pdurbin]

@DieuwertjeBloemen also mentioned problems accessing notifications from admin accounts with many notifications: https://dataverse.zulipchat.com/#narrow/channel/379673-dev/topic/Notifications.20API.20usage.20and.20future/near/533123865