Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
haarli opened this issue Sep 25, 2023 · 4 comments · Fixed by #9955
Closed
Milestone

Comments

@haarli
Copy link
Contributor

haarli commented Sep 25, 2023

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 (

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
Copy link
Member

qqmyers commented Sep 25, 2023

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
Copy link
Contributor Author

haarli commented Sep 26, 2023

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
Copy link
Member

qqmyers commented Sep 26, 2023

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

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 added a commit to MPDL/dataverse that referenced this issue Sep 27, 2023
@haarli
Copy link
Contributor Author

haarli commented Sep 27, 2023

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants