Dataset status change isn't visible after publish on auto refreshed dataset page (v5.14)

[haarli]

This behaviour only occurs in v5.14. It seems to be fixed in v6.0.
However, we're looking for a quick fix which we can apply to v5.14.

There's a discussion on Zulip chat about this: https://dataverse.zulipchat.com/#narrow/stream/378866-troubleshooting/topic/dataset.20status.20change.20isn't.20visible.20after.20publish.20.28v5.2E14.29

Normally, when publishing a dataset, the dataset page refreshes every few seconds and then displays the published dataset.
With 5.14 however, the page is still refreshed, but at the end the old draft version is displayed, although the dataset is in status published. If you refresh the page manually, the message "Info – The "DRAFT" version was not found. This is version "1.0". " is displayed. But if you go back to the list, and open the dataset again, it's in the correct state (published)

In the background the log shows a null pointer exception:

[2023-09-22T13:47:14.081+0200] [Payara 5.2022.5] [SCHWERWIEGEND] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=98 _ThreadName=http-thread-pool::http-listener-1(2)] [timeMillis: 1695383234081] [levelValue: 1000] [[
    javax.faces.view.facelets.TagAttributeException: /dataset.xhtml @93,82 test="#{not empty DatasetPage.getSignpostingLinkHeader()}" /dataset.xhtml @93,82 test="#{not empty DatasetPage.getSignpostingLinkHeader()}": java.lang.NullPointerException
    at com.sun.faces.facelets.tag.TagAttributeImpl.getObject(TagAttributeImpl.java:318)
    ...
    Caused by: java.lang.NullPointerException
    at edu.harvard.iq.dataverse.DatasetPage.getSignpostingLinkHeader(DatasetPage.java:6149)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.base/java.lang.reflect.Method.invoke(Method.java:566)
    at javax.el.ELUtil.invokeMethod(ELUtil.java:236)
    ... 84 more
    ]]

The method DatasetPage.getSignPostingLinkHeader (

dataverse/src/main/java/edu/harvard/iq/dataverse/DatasetPage.java

Line 6148 in 9f4ddbb

if (!workingVersion.isReleased()) {

) is called a lot of times during the publishing process. The last 3 times it's called during the auto refresh phase, workingVersion is null. This leads to the null pointer exception.

Fixing this method does not help, because then another NPE is thrown. The actual problem is that methods are called on DatasetPage when the page is refreshed, but workingVersion and dataset are null.

Here's a screencast showing this behaviour:
https://github.com/IQSS/dataverse/assets/5524896/c1262c31-5e12-4312-b0be-618a3112e102

Would be really helpful if anyone is aware which change from v5.14 to v6.0 fixedx this behaviour.
Thank you!

[qqmyers]

FWIW: My guess (not confirmed) is that the fix is from #9835. When the page updates to show the publication in progress message the persistentId in the URL is switched to an encoded form e.g. persistentId=doi%3A10.70122%2FFK2%2FLT4HCQ and #9835 is a fix to allow a PID with %3A to be recognized correctly. As far as I know, there were no changes to the signposting code in DatasetPage between 5.14 and 6.0 (where workingversion is null). Whether that fixes all cases where workingversion is null in the signposting call is tbd. Since signposting probably isn't needed during page refreshes, one quick code fix, if needed for other cases, could be to just return null if workingversion is null.

[haarli]

Thank you @qqmyers for the suggestions. Unfortunately, both fixes do not solve the problem.
I've added the code line from #9835 to our 5.14 code, but it doesn't make any difference. The encoding was correct before in our case.
About checking if workingversion is null in the signposting code: I already tried this before. But as I said in the OP, then another NPE is thrown. A lot of getter methods are called on DatasetPage during the refreshes, getSignPostingLinkHeader is just the first. If this one is fixed, then the NPE is thrown in another place:

[2023-09-22T14:02:53.418+0200] [Payara 5.2022.5] [SCHWERWIEGEND] [] [javax.enterprise.resource.webcontainer.jsf.context] [tid: _ThreadID=97 _ThreadName=http-thread-pool::http-listener-1(1)] [timeMillis: 1695384173418] [levelValue: 1000] [[
javax.faces.view.facelets.TagAttributeException: /dataset.xhtml @319,197 test="#{!((showSubmitForReviewLink or showReturnToAuthorLink or not empty DatasetPage.allowedExternalStatuses) and showPublishLink)}" /dataset.xhtml @319,197 test="#{!((showSubmitForReviewLink or showReturnToAuthorLink or not empty DatasetPage.allowedExternalStatuses) and showPublishLink)}": java.lang.NullPointerException
...
Caused by: java.lang.NullPointerException
at edu.harvard.iq.dataverse.SettingsWrapper.getAllowedExternalStatuses(SettingsWrapper.java:714)
at edu.harvard.iq.dataverse.SettingsWrapper$Proxy$_$$_WeldClientProxy.getAllowedExternalStatuses(Unknown Source)
at edu.harvard.iq.dataverse.DatasetPage.getAllowedExternalStatuses(DatasetPage.java:5885)
at jdk.internal.reflect.GeneratedMethodAccessor1482.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at javax.el.BeanELResolver.getValue(BeanELResolver.java:299)
... 110 more
]]

The root problem is that workingVersion and dataset must not be null when the dataset page refreshes. But in 5.14, at the end of the refresh phase, they suddenly are.

[qqmyers]

From what I can tell, a change in #9725 causes this problem in v5.14 but not in v6.0. It appears that adding a check for versionId being null at

dataverse/src/main/java/edu/harvard/iq/dataverse/DatasetPage.java

Line 2865 in 5fc7b30

and setting it to workingVersion.getId() before workingVersion is set to null is a work-around. In 6.0, it appears that versionId is still set at this point, as is workingVersion itself.

[haarli]

@qqmyers Thank you, awesome.
I added your suggestion to our code: MPDL@b7c6593
And it seems to work fine now.

I will close this issue as this is a fix for an older version which isn't relevant for the current main development branch.