Introducing Dandiset DOIs

[asmacdo]

• POC Implementation for Design document for the Zenodo like DOI per dandiset #2012

Example of Dandiset DOI (note -- no version) : 10.80507/dandi.000004

Remaining TODOs:

• Update Design document for the Zenodo like DOI per dandiset #2012, which should be merged before this comes out of "draft PR"
• Implement support in to_datacite within dandi-schema: enh: allow creation of dandiset dois (contrasted to a version doi) dandi-schema#297
• Use DJANGO_DANDI_DOI_PUBLISH to determine whether DOIs are Findable
• Handle Datacite validation failures (if not enough to make findable, revert to draft)
• On update, if draft doi, "publish" to Findable
• Reduce repetition in Datacite API usage, probably create a minimal client?
• add tests
• Move (and combine?) "mid level" functions from publish/ dandiset/ views/version/ unembargo/ to doi.py
• dd Dandset DOI to vue for draft version
• management command ot populate DOIs for existing public dandisets
• Audit code comments-- this stuff moved around a lot, and also theres a lot of AI verbosity
• Add hand-QA checklist to this PR
• For handle publication does, catch datacite client exceptions since we are creating 2 dois
• Rebase schema PR on Isaac's changes
• Be more consistent about exception handling and logging
• consider adding audit related records on DOI operations
• reconsider using schema's Dandiset instead of constructing unvalidated
• Decide how to handle "delete" there is no usage of the REST endpoint AFAICT! Admin delete uses a different endpoint

[asmacdo]

Getting closer to completion now, but there are a few things I have not yet been able to verify:

• Deletion of dandisets: I should have superuser but I dont see anything on /admin so I cant actually delete the dandisets to verify DOI delete/hide behavior.
• Findable/Registered DOIs: when DANDI_DOI_PUBLISH is true, we create findable DOIs which might behave differently. I'll need to patch the DOIs manually to prevent collisions in our test datacite api, and modify dandischema to allow that. A PITA, so I'm doing other stuff first.
• Unembargo workflow: I ran into 3 issues:
  • contact person missing
  • license missing
  • saving license

[asmacdo]

Previously, we would use settings.DANDI_DOI_API_PREFIX or '10.80507'

If api prefix is not set, DOI API operations should be prevented by is_configured() so I think this is appropriate

[yarikoptic]

I would say that we should actually abort deletion of dandiset if something goes wrong with DOI deletion so we do not cause inconsistency

[asmacdo]

todo should still be a celery task, but we should make sure it passes or roll back transaction

[yarikoptic]

just posting an exception we observerd while trying locally. Ideally should be more graceful I think

[yarikoptic]

ran into

[2025-06-02 19:39:54,744: ERROR/ForkPoolWorker-8] dandiapi.api.tasks.create_dandiset_draft_doi_task[202f05fc-00ae-4f02-8a16-6ff97cf39bcd]: Failed to create Draft DOI for dandiset 000001
Traceback (most recent call last):
  File "/home/yoh/proj/dandi/dandi-archive-master/dandiapi/api/tasks/__init__.py", line 124, in create_dandiset_draft_doi_task
    _create_dandiset_draft_doi(version)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^
  File "/home/yoh/proj/dandi/dandi-archive-master/dandiapi/api/doi.py", line 52, in _create_dandiset_draft_doi
    dandiset_doi, dandiset_doi_payload = datacite_client.generate_doi_data(
                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
        draft_version,
        ^^^^^^^^^^^^^^
        version_doi=False,
        ^^^^^^^^^^^^^^^^^^
        event=None,  # Draft DOI
        ^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/home/yoh/proj/dandi/dandi-archive-master/dandiapi/api/datacite.py", line 115, in generate_doi_data
    datacite_payload = to_datacite(metadata, event=event)
  File "/home/yoh/proj/dandi/dandischema/dandischema/datacite/__init__.py", line 248, in to_datacite
    ).pop()
      ~~~^^
IndexError: pop from empty list

[asmacdo]

+1 we can handle that more gracefully. This exception occurred because the Dandiset was created by the superuser without a name. So FWIW even if we relax how to_datacite sets that value it will still be an invalid DOI payload.