Additional context from now-closed-as-duplicate #7019:

In #5093/#6901 we added support for reserving DOIs with Datacite.

There may be some steps to get DOIs into a reserved state, and we want to make sure that all drafts remain publishable.

Edit: there are definitely some steps needed to reserve the unreserved Datacite DOIs. (that's the API described above). None of the existing unpublished draft datasets have reserved DOIs just yet. (none of them exist in the db on the Datacite side). They all need to be reserved. The only ambiguity is how urgent this task is, to get them reserved after upgrading to d5. Specifically, whether it is indeed required for the unpublished drafts to "remain publishable" (more below).

We also don't want Dataverse to have old drafts marked as reserved when they are not actually reserved.

Edit: It sounds like there is no additional "reserved" marking. What serves as the indicator of the DOI having been reserved is the non-null globalidcreatetime (per @pdurbin). So the question is, do unpublished drafts have this timestamp populated, or not? If it is the former, they will appear "reserved" (and publishable), even though they are not reserved. If the latter, they will become unpublishable after the d5 upgrade. On a quick check of the prod. db, there are 4K local (non-harvested) datasets with null publicationDate (presumably, most are unpublished drafts) AND null globalidcreatetime. These include a ton of recently created drafts; so yes, it does look like a) drafts are not currently getting the timestamp populated on create and b) these drafts will indeed become unpublishable as soon as we upgrade.
There are also 3K datasets with null publicationDate AND non-null globalidcreatetime... not sure what's up with these. (none of these are super recent; there's one from 2019; then a whole bunch from 2018 and earlier; ok, the answer may be that some of these were drafts created back under EZID; and some are even more ancient datasets created when we were using handles?)

There should be a step about running an API to mark drafts as reserved (whether a single time or on a regular cron)

Edit: The previous paragraphs were about handling the existing unpublished drafts after the upgrade. That's a one-time task.
There is also a question of handling it going forward. (because some DOIs may be failing to get reserved on create - because Datacite is down, for example). So these will need to be regularly addressed. It'll likely not going to be a frequent condition. But we need to tell the admins that they'll need to either set up a cron job; or do it by hand (once in a while); or to keep an eye out for users complaining about the publish button being blocked - and then attending to it...

@scolapasta Thanks for discussing and estimating - is the plan to handle this through a release note or through code?

Release note.

Another thing we can recommend - and should definitely do in our prod. - would be to add a few extra words to the warning banner about the upcoming upgrade; something along the lines of "This Dataverse will be down between ... and ... for a planned upgrade. Please note that users may experience temporary problems publishing previously unpublished drafts immediately after the upgrade".
We can keep a similar warning up after the upgrade as well, until all the unpublished DOIs are reserved.

I've tested the case where we have (in v4.20) an unpublished draft with the null GlobalIdCreateTime, that DOES exist on the Datacite side - what happens when we run the new reserve API on it?
This case would usually be the result of a previous attempt to publish the dataset that failed. (failed on our end - but not before the dataset got registered with Datacite). All the real life cases we've had in production in the past where the DOI would suddenly change during publishing were due to this scenario. (on publish Dataverse would think it was registering a new identifier; but Datacite would respond "already exists" - Dataverse picks and registers the new DOI).

A real example of an unpublished draft with a registered DOI: 10.7910/DVN/CAL9UW

I was afraid/expecting that the same exact exchange was going to happen when we try to reserve the DOI for a case like that. Resulting in an unnecessary DOI change again. I was preparing to address this by recommending that the admins review their unpublished draft DOIs, find such cases and, if exist, mark them as "reserved", before running the reserve API on the remaining "real unreserved" ones.

However, testing (with both a test and prod. authorities) has confirmed that the reserve API simply proceeds to update the existing record; nothing fails, the fact that it exist is not a problem - and the dataset ends up with the same, existing DOI that is now "reserved" in the Dataverse db as well.

So this is good - fewer steps to document and perform after the upgrade; it also sounds like starting v5.0 there will not be a realistically possible case where the DOI will actually have to change before the dataset is published. (yay!)

But this brings up a question - is this the behavior we want? Do note that if this were a genuine collision (extremely unlikely - but possible! somebody using the same Datacite account went and registered this very identifier for something on another site) - it would not be detected. Are we ok with this?

(even if we are not entirely ok with this, the condition is probably too unlikely to bother changing it before v5.0. but we could discuss changing it further down the road. or not?)

I'm fine with the current behavior. If I'm a sysadmin running a few systems that share a DOI authority, I can always reduce the chance of a conflict by giving a unique shoulder to each system rather than hoping that the various systems play nicely together. And like you say above, if we can always revisit this post 5.0 if there's trouble.

The reserve code could check to see if the DOI exists before trying to create it (with a call that creates or just updates the metadata if the DOI exists), but I wouldn't hold up 5 for that - as Phil says it's probably not a good practice to share authority/shoulder between systems, and I don't think many installations are sharing, and the collision chance should be minimal (unless Dataverse is coming back with the same DOI after a failure as has been the case with the publication collisions we've seen).

@qqmyers @pdurbin
Agree, I don't think we should worry about this being a 5.0 issue.
Mostly wondering if it's worth opening a new issue. A reasonable check could be something like this: if the doi exists on the Datacite end, AND the url is pointing somewhere else, other than this dataverse - then it's likely an actual conflict. (and then it could generate a new id; or just give up and let the admin handle it). Otherwise, just proceed to update it.

@djbrooke - this task mentions asynchronously, but I don't know that it was intended to address making the reservation of DOIs and publicizing them at publication time asynchronous, i.e. being completed outside the save/publish call itself. Is that something to discuss? Create a separate issue for? Mostly thinking about the time required to register/publicize large numbers of file DOIs that the user has to wait through.

@qqmyers thanks (and thanks @kcondon for discussing separately) - yes, if we can create a different issue that'd be great. If you have some ideas it'd be great for you to create it, or I can - let me know.