The wrong child works are attached to parents

[crisr15]

Story

https://assaydepot.slack.com/archives/C030UPFFP2A/p1707761167626329

Initially it was discovered that an identifier we thought was unique was not. So child works were being added to the wrong parent by this identifier. We believe this issue was fixed but the following records were discovered with the wrong child files.

Hello hello, here's a sample of some records for whom I'm still seeing mismatched children in AMS2:
cpb-aacip-207-33dz0cjb
cpb-aacip-191-010p2p45
cpb-aacip-207-375tb5z2
cpb-aacip-207-009w0vxr
cpb-aacip-191-612ngm9x
cpb-aacip-191-39x0kb6x
If you'd like a larger sample, anything from this link that was contributed from outside New Mexico or Georgia are the same type of mismatches https://americanarchive.org/catalog?f%5Bspecial_collections%5D%5B%5D=new-mexico-public[…]-collection&sort=asset_date+asc&f[access_types][]=digitized

We need to evaluate if these are new works and this issue needs to be re-evaluated, or if these are old works and we need to outline a strategy to fix the old records.

Acceptance Criteria

• We have determined if these works were last updated after the fix for the identifiers was in place.
• If these works are more recent a ticket for re-evaluating our fix has been created.
• If these are from before the fix a ticket with plans for how to fix old records has been created.

Implementation Suggestions

given the local_instantiation_identifier and the importer name (directory of the xml files), find the xml file in that directory with the identifier and copy it to a new directory

given a directory of xml files, find all assets with the asset id in each file and remove them and any children from the system

given a directory of xml files that does not have corresponding assets or children, create a bulkrax importer that points at that directory and run it like normal

Code exists to thoroughly delete an asset and all its children (including sipity objects) (AssetDestroyer). This should be used since that step is very important (not sure if that logic has been valkyrized yet — it most likely has not).

Every record is in postgres. Most records are also in fedora. If postgres record disappears and fedora record doesn’t, valkyrie will re-migrate the fedora data to postgres. DELETE FEDORA VERSION OF RECORDS FIRST

Update AssetDestroyer to also destroy records and their children from valkyrie (postgres). Add #destroy_asset_resource_by_id and invoke it after the fedora version

Notes

The previous ticket may be on the Devops repo.

[mivillesvik]

It was mentioned that a list of records known to be affected by this issue would be helpful, so I'm dropping this here! This is only a snapshot and is NOT the entire list of affected records

Snapshotofrecordsaffectedbymismatchedchildren.txt

[bkiahstroud]

The remainder of this task (deleting and recreating the broken Instantiations) was handed off to Drew during a meeting in May