NullPointerException in DOI creation causes silent registration failures during dataset creation

[jamessi1989]

What steps does it take to reproduce the issue?

• When does this issue occur?

This issue occurs intermittently during dataset creation when author affiliations are selected from the ROR (Research Organization Registry) autocomplete dropdown. The failure is timing-dependent, occurring approximately 10-50% of the time depending on system load.

• Which page(s) does it occurs on?

Dataset creation page (dataset.xhtml?ownerId=X&editMode=CREATE)

• What happens?

1. User creates a new dataset and fills in metadata
2. User adds an author and types in the "Author Affiliation" field
3. User selects an organization from the ROR autocomplete dropdown (e.g., "UPC - Universidad Politécnica de Cataluña")
4. User clicks "Save"
5. Dataset saves successfully and DOI identifier is assigned (e.g., doi:10.82201/XXXXXX)
6. However, the DOI is NOT registered with DataCite
7. Database shows: identifierregistered=false and globalidcreatetime=NULL
8. User sees "DOI not reserved" banner on the dataset page
9. Logs show: java.lang.NullPointerException in AbstractPidProvider.getTargetUrl()

This is a silent data integrity failure - the dataset appears to save successfully, but the DOI is not actually registered with the PID provider.

• To whom does it occur (all users, curators, superusers)?

All users who create datasets. The issue is not permission-based or role-based.

• What did you expect to happen?

Expected behavior:

• Dataset saves successfully
• DOI is registered with DataCite
• Database shows identifierregistered=true and globalidcreatetime has a timestamp
• No "DOI not reserved" banner appears
• DOI resolves correctly

Which version of Dataverse are you using?

Confirmed on both Dataverse 6.5 AND 6.8

Production environment (6.5):

• Dataverse: 6.5
• Payara: 6.2023.8
• PostgreSQL: 16.6
• OS: Rocky Linux 9

Test environment (6.8):

• Dataverse: 6.8
• Payara: 6.2023.8+
• Same bug occurs

Configuration:

• DOI Provider: DataCite (REST API)
• External Vocab Support: Enabled (ROR + ORCID)
• JVM properties: dataverse.pid.default-provider=datacite-prod

Any related open or closed issues to this bug report?

None found.

This appears to be an unreported race condition in the DOI creation transaction flow.

Screenshots:

Log excerpt showing the NullPointerException pattern:

[2025-10-30T08:23:36.855] FINE: DataCiteDOIProvider.createIdentifier
[2025-10-30T08:23:36.856] FINE: AbstractPidProvider.getMetadataForCreateIndicator
[2025-10-30T08:23:36.857] FINE: AbstractPidProvider.getTargetUrl
[2025-10-30T08:23:36.860] WARNING: DataCiteDOIProvider
  Identifier not created: create failed
java.lang.NullPointerException
[2025-10-30T08:23:36.860] INFO: AbstractDatasetCommand
  Call to globalIdServiceBean.createIdentifier failed: java.lang.NullPointerException

Database state after failure:

SELECT identifier, identifierregistered, globalidcreatetime
FROM dvobject WHERE identifier = 'EWDNT1';

identifier | identifierregistered | globalidcreatetime
-----------+----------------------+-------------------
EWDNT1     | false                | NULL

Root Cause:

The getTargetUrl() method in AbstractPidProvider attempts to call dvObjectIn.getGlobalId().asString(), but getGlobalId() returns null because the GlobalId hasn't been assigned yet during the DOI creation process. This is a race condition in the transaction flow.

Code location: src/main/java/edu/harvard/iq/dataverse/pidproviders/AbstractPidProvider.java

Failing line (approximate):

public String getTargetUrl(DvObject dvObjectIn) {
    return SystemConfig.getDataverseSiteUrlStatic()
         + dvObjectIn.getTargetUrl()
         + dvObjectIn.getGlobalId().asString();  // ← NPE: getGlobalId() returns null
}

Reproduction Steps:

1. Enable debug logging:

   asadmin set-log-levels edu.harvard.iq.dataverse.pidproviders=FINE
   asadmin set-log-levels edu.harvard.iq.dataverse.pidproviders.doi.datacite=FINEST

2. Create new dataset with:

   • Title: "Test Dataset"
   • Description: "Testing DOI bug"
   • Author Name: "Test Author"
   • Author Affiliation: Select an organization from ROR dropdown (don't just type text)
     • Type "Universidad" or "UPC" or "Catalan"
     • Select from autocomplete dropdown

3. Click Save

4. Check logs for NullPointerException

5. Check database:

   SELECT identifier, identifierregistered, globalidcreatetime
   FROM dvobject
   WHERE protocol = 'doi'
   ORDER BY createtime DESC
   LIMIT 1;

If identifierregistered = false and globalidcreatetime IS NULL, the bug occurred.

Workaround (100% Success Rate):

Users can avoid this issue by:

1. Create dataset with minimal metadata (title + description only, no author)
2. Save → DOI registers successfully ✅
3. Edit dataset to add author with ROR affiliation
4. Save changes ✅

This works because the DOI is already registered during the initial save, and the edit operation doesn't trigger DOI recreation.

Impact:

In our production environment:

• 10 datasets affected since October 27, 2025
• Failure rate: 10-50% when ROR affiliations are selected
• 6 different institutions affected (not institution-specific)
• All required manual remediation

Severity: High - Silent data integrity failure affecting persistent identifiers

Are you thinking about creating a pull request for this issue?

Not currently feasible

nullpointer-example-log.txt

We have extensive debug logs and can provide additional information as needed. We're committed to helping resolve this issue.

[qqmyers]

Thanks for the detailed report! I'm looking into it. From what I can see, the problem should be generic for any external vocab service where we're caching information for exports, perhaps seen mostly with ROR if their server is slower in responding.
I can hopefully come up with bug fix but, if I can't reproduce the problem locally, I may ask for your help in testing.

In the meantime, I'll note that the problem is not fatal - we register the PID/DOI when creating the dataset to help avoid potential conflicts in cases where something other than Dataverse is creating PIDs using the same DataCite account. If you are not doing that, there's no chance of a DOI being reused. We put up the warning label, but otherwise, when you publish, the PID should get registered and made findable without any problem. (At least this works when the PID is not registered because the DataCite connection was down/misconfigured when the dataset was created. From your database info above, it looks like the result in the database is the same as when DataCite is unavailable.)

For work-arounds/fixes, you should be able to use https://guides.dataverse.org/en/latest/api/native-api.html#reserve-a-pid to reserve the PID and get rid of the warning. To prevent new issues, I think you can disable the ROR caching step by removing the contents of the retrieval-filtering section of the configuration, e.g. removing https://github.com/gdcc/dataverse-external-vocab-support/blob/7c4ae70f850522a966cd8e3831a51d59be8fca96/examples/config/authorsOrcidAndRor.json#L56-L73 . The potential downside of that is that the DataCite XML export/metadata sent to DataCite (at least in 6.8) will only include the numeric ROR and not the institutional name (this can be fixed for affected datasets after a bug fix is made). (Also - I'm not sure when the ROR support was added in the DataCite xml export - 6.4 may not even be adding it.).

[jamessi1989]

Hi thanks for the prompt and detailed response!

Just adding some more information I will follow up with more detailed tests on Monday but :

We weren't able to replicate it in this enviroment where, in theory, it matches our test env.
https://demo.dataverse.org/dataset.xhtml?persistentId=doi%3A10.70122%2FFK2%2FAAJ4CZ

We are slightly confused not to see the same error here - do you know of any enviromental differences ?

[qqmyers]

FWIW: I checked that demo.dataverse.org has the same retrieval-filtering entry as in the example (it's actually https://github.com/gdcc/dataverse-external-vocab-support/blob/7c4ae70f850522a966cd8e3831a51d59be8fca96/examples/config/authorsOrcidAndRor.json#L17-L34 - I pointed to the wrong one yesterday).

During dataset creation, the code tries to look up the ROR, and any other ext. vocab terms used, in the Dataverse database and, if any don't exist, it call the ROR service (and other external vocab services) to get and parse JSON as defined in the retrieval-filtering. For ROR, that includes getting the name. So one potential difference is whether the ROR being used is already cached or not. Once it's cached, it won't be retrieved again unless/until it is cleared from the db.

I've scanned through the code and so far I don't see anything asynchronous that could cause a race - we just wait for the call to the external service to complete. I also don't see (so far) any error types that we don't catch. Caching the information is optional, so if it fails, we should just continue. So - no root cause yet. I may just work to further isolate this code, e.g. pull it outside the transaction - seems like a reasonable thing regardless.

[qqmyers]

I just encountered this on another machine - could it be that you have
"retrieval-uri": "https://api.ror.org/organizations/{0}" rather than "retrieval-uri": "https://api.ror.org/v1/organizations/{0}" ?

(I can see how this can cause a failure - not sure if it can succeed sometimes - perhaps for RORs where the organization only has one name? Or ones that were cached before the default changed to v2? It would be consistent with adding a ROR after creation working - we don't recreate the DataCite xml again until you publish.)

FWIW: ROR changed the default version of their API to v2 a while ago (I sent a google group message) and v2 changes the json structure they use enough to break our parsing. When a ROR isn't cached, we also had/have a bug, fixed in #11782 (which missed getting into 6.8) that would cause creation of the DataCite.xml to fail. Changing to use v1 fixes the immediate problem.

With their v1 going away as of ~12/31/2025, there are additional fixes in Dataverse and the ROR script to support using v2 in the works: see gdcc/dataverse-external-vocab-support#46 which has an overview.

[jamessi1989]

Thanks @qqmyers!

We updated our configuration to use the v1 endpoint, but we're still seeing some ROR-related errors with new datasets (possibly a caching issue - we haven't fully investigated yet).

More importantly though, datasets that were created during the bug period can't be published, even after the configuration fix. The DOIs exist at DataCite but publishing fails with a NullPointerException in DataCiteDOIProvider.publicizeIdentifier().

Here's what we're seeing:

Test case: doi:10.82201/CWCU4Q

• Created Oct 29 with ROR affiliation → DOI partially registered
• Database shows identifierregistered=true
• DOI exists at DataCite in "draft" state but with `url: null
• Trying to publish → API returns "OK" but actually fails with NPE
• Dataset stays stuck in DRAFT

We've tried publishing it multiple times after applying different fixes (ROR v1, updating the DOI URL at DataCite, etc.) but it keeps failing with the same NullPointerException.

We have 8 datasets in this state and users can't publish them through the normal workflow. The only workaround we've found is manually updating the DOI at DataCite and then updating the database directly.

Any suggestions on:

1. How to get these stuck datasets publishable?
2. Whether we need to restart Payara/clear cache for the ROR v1 fix to fully take effect?

---

Environment: Dataverse 6.8, DataCite production (dataverse.bsc.es)
Logs/details: Happy to provide more info if helpful

error-logs (1).txt

[qqmyers]

OK - glad to hear it's from the v1 issue. I'd suggest clearing bad values from the ExternalVocabularyValue table. You can do that in the database (truncate externalvocabularyvalue; or search for and delete the specific ROR values). When you try to publish, or edit metadata, etc., Dataverse will try to regenerate any missing values (ORCIDs, RORs, etc.), so it should get the RORs correctly via the v1 api and that should avoid the NPE.

[pdurbin]

@juancorr it's possible you're suffering from this as well, based on what you posted at #troubleshooting > [v6.6] Cannot publish dataset after upgrade @ 💬