Prefixes appear to be assigned to 2 members/consortium organizations at the same time

[MaryHirsch]

Expected Behaviour

Repository transfer workflow moves the whole repository and prefix under the new consortium organization

Current Behaviour

Some prefixes appearing in both old and new accounts

Steps to Reproduce

Examples:

Prefix 10.17632 under BL and ELSEVIER https://doi.datacite.org/providers/bl/prefixes/10.17632
Prefixes 10.22022, 10.25536, 10.25924 and 10.34876 under TUW and old consortium organization e.g https://doi.datacite.org/providers/fhv/prefixes

Context (Environment)

Fabrica

Hypothesis

Detailed Description

Possible Implementation

Front conversations

[richardhallett]

This isn't a bug as such, but the problem is actually the prefixes are assigned to the repository but the repository moved to a new member(provider), however the prefixes are not moving in the original member to the new member.

@kjgarza I assume this was never meant to transfer the prefixes that are associated to a member(provider) to the new parent of the repository?

This can be solved manually by transferring the prefixes from old provider to new.

[richardhallett]

Discussion with @kjgarza this actually should re create the new prefix relations, so there might actually be a bug contrary to my previous comment. I will investigate further.

[richardhallett]

This appears to be an indexing problem, the database has the correct records but the index is showing up in both providers see:

[MaryHirsch]

another example of prefixes that were transferred but still appear in the old repository (in this case the prefixes and DOIs were transferred via the old workflow): https://doi.datacite.org/repositories/dcco.anschutz/prefixes

[richardhallett]

The data has been fixed for the original listed members(providers), I did this by reindexing and switching to new index.
I can't see any reason why the repository transfer workflow should not work, if this reoccurs we can reopen this for further investigation.

As for the other example of DCCO.ANSCHUTZ if the prefix was not moved from the member(provider) in the old workflow then they will still exist in that member(provider) and needs to be manually moved.

[richardhallett]

Reopening with new example post data fix

prefix: 10.26031
old cosortium org: QJRI
new consortium org: CNAR
repo: ETHZ.ZHAW-ANIURIS

[richardhallett]

10.26031 appears to be not removed from the ES index for provider association, same as others.
This suggests the code is not working as expected.

[richardhallett]

I have fixed 10.26031 but only by manually reindexing and therefore removing duplicates.
I am looking at adding additional logging to potentially help identify the root cause.
I have the suspicion this is due to a race condition where updates happen at same time and data is accidentally re-created.

[richardhallett]

After further investigation it turned out not to be a race condition but just the fact the model changes were not performing updates to the ES index.

This was fixed under datacite/lupo#684 and deployed.
All prefixes were re-indexed at time of deployment.