Open jamiefolsom opened 3 months ago
@jamiefolsom - I took a look into this, and I'm making some assumptions, but this is what I think is going on:
I took a look at the place records for "Paris" and "Amsterdam" in the "Rumpf Staging" project on staging.coredata.cloud (there doesn't appear to be a "Rumpf" project on Core Data production). All of the records were both created and updated on 2/8/24, which is assume is when the initial import took place. I also pulled a backup of the database locally to test the merge functionality and was unable to reproduce a situation where it created duplicate records. So I don't believe that there is an issue with the merge records functionality, or that these records were created as a result of merging.
I was, however, able to page through some of the records and notice the same uuid
values appearing on several pages. This is not a result of duplicate records existing in the database, but rather non-deterministic ordering when sorting by columns with non-unique values. I've opened a PR further upstream in the resource-api
repo, as this issue is likely to affect other projects.
After looking at the correct database, I was able to reproduce this issue only by initiating the merge, clicking the "Cancel" button, then initiating the merge again prior to the first merge finishing.
To prevent users from making extra API calls to merge, we should disable all buttons while the request is processing.
Specifically on the Sapientia/Rumpf project, merging duplicates for "Paris" has resulted in duplicates, same for Amsterdam.