`sequentialNumber` identifiers fail on create instead of retrying

[pameyer]

With an installation using sequentialNumber as :IdentifierGenerationStyle, dataset creation will fail if using an already existing identifier instead of retrying (aka - moving up the sequence to the next available one). Observed w\ test DOI shoulder and fresh database; low urgency as most common cause is development w\ test shoulder.

[pameyer]

Oddly, this appears to indicate that DOIDataCiteServiceBean.alreadyExists is broken; since DatasetServiceBean.isIdentifierUniqueInDatabase already has logic for it.

[pameyer]

Did some troubleshooting / investigation in https://github.com/IQSS/dataverse/tree/3957-fxseq

[pameyer]

Overall behavior confirmed with develop 22090e2; initial description slightly inaccurate. create succeeds (when it arguably shouldn't) with existing identifier; publish fails (identifier already in use).

Expected behavior confirmed w\ 3957-fxseq 8176cdd.

Current evaluation: Root cause is assumption that "pid does not exist in DataCite" (DataCiteRESTfullClient.testDOIExists) is equivalent to "pid does not exist in DOI system". Default dev environment using EZID test shoulder; test shoulder not propagated (and no reason why it should propagate). Depending on propagation time, could impact default RandomString identifier scheme.

Questions for CR:

• Thoughts on evaluation?
• Ballpark propagation time between DataCite and EZID with production configuration? Is this long enough that it makes sense to change behaviour of RandomString identifiers too?
• appropriate exception to throw for "this operation not supported on this identifier type"?

[sekmiller]

In our design we are assuming that only one installation will be writing to a give DOI namespace hence the reliance on duplications in the database without reaching out to the publicly to see if an identifier has been registered. This, of course, is not true for the test environments. As far as propagation time goes, it should be fairly quick, since it all happens in either the create dataset or publish dataset command method (depending on when the identifier is actually registered.)
Adding a isPublic test isn't a bad idea, but it's hard to see it coming into play except in the test environment (or multiple installations using the same DOI namespace.)

[sekmiller]

Based on discussion with @pameyer, we've decided to close this ticket. The issue will only occur where there are multiple installations writing to the same namespace. This happens in test environments since there is only one identifier namespace for all testers of DataCite/EZID. However, in production we should be safe in the assumption that each installation will have its own identifier namespace.

[pameyer]

And for future reference; the DataCite <-> EZID propagation time is irrelevant in production (the database is the source of truth under a given shoulder).