Metadata-only re-ingest fails to update METS.xml after first re-ingest (v1.19)

[Thales Oliveira Torres Brasil]

Hello,

I'm experiencing an issue with metadata re-ingests in Archivematica 1.19 where METS.xml is only updated on the first re-ingest, but subsequent re-ingests
fail to update the METS file. This occurs across all three re-ingest types.

Environment:
- Archivematica version: 1.19
- Method: Both Dashboard UI and API

Steps to Reproduce:

1. Create and ingest a transfer with initial metadata (metadata.csv/metadata.json)
2. Store the AIP successfully - METS.xml contains correct initial metadata
3. Perform first re-ingest with updated metadata (tested with all three types):
- Metadata-only: Via UI (Re-ingest → Metadata only → Add metadata files → Approve) or API
- Partial re-ingest: With metadata updates
- Full re-ingest: With metadata updates and processing configuration
4. First re-ingest completes - METS.xml is correctly updated with STATUS="updated" dmdSec ✓
5. Perform second re-ingest (same type) with new metadata changes
6. Second re-ingest completes - METS.xml is NOT updated ✗

API Flow (for metadata-only):
- POST /api/v2/file/<UUID>/reingest/ (Storage Service)
- POST /api/ingest/copy_metadata_files/ (Dashboard)
- PATCH /api/v2/file/<UUID>/ (Storage Service)
- POST /api/ingest/reingest/approve (Dashboard - undocumented endpoint)

Expected Behavior:
METS.xml should be updated every time a re-ingest is performed with metadata changes, allowing multiple metadata updates throughout the AIP lifecycle.
According to the documentation, metadata-only re-ingest should update the dmdSec with STATUS="updated", and this should work on subsequent re-ingests as
well.

Actual Behavior:
- First re-ingest (any type): METS.xml updates correctly, new dmdSec added with STATUS="updated"
- Second and subsequent re-ingests (any type):
- metadata.json/metadata.csv files inside the AIP package are updated correctly
- METS.xml remains unchanged - no new dmdSec created
- This happens with both CSV and JSON metadata formats
- Occurs with metadata-only, partial, and full re-ingest types

Use Case:
We need to allow clients to update metadata multiple times as records evolve in our repository. The current behavior limits us to only one metadata update
per AIP, which is problematic for our long-term preservation workflow.

Related Issue:
This seems potentially related to a similar problem reported in 2019:
https://groups.google.com/g/archivematica/c/HktnBn0Tr7w/m/gqekyzhNBwAJ

In that thread, the issue was about metadata updates not being reflected in METS.xml during re-ingest. However, our specific case shows that it works once
but fails on subsequent attempts, which may indicate a regression or a different manifestation of the same underlying issue.

Questions:
1. Is this a known limitation or bug in version 1.19?
2. Is there a workaround to enable multiple metadata updates?
3. Should we expect METS.xml to be updated on every re-ingest with metadata changes, regardless of re-ingest type?
4. Is there any technical reason why only the first re-ingest updates the METS file?
5. Could this be related to how Archivematica checks for existing STATUS="updated" dmdSec entries?

Any guidance would be greatly appreciated.

Thank you!

[Thales Oliveira Torres Brasil]

[Murilo Souza dos Santos]

Hi there,

I can confirm that I am experiencing exactly the same issue, but on Archivematica version 1.17.1.

Just like you described, the first metadata re-ingest updates the METS.xml perfectly, but any subsequent attempts update the files inside the AIP (metadata.json/csv) while leaving the METS file completely untouched (no new dmdSec is created).

Since it's happening in 1.17.1 as well, it seems this bug has been around for a while and wasn't introduced in 1.19. Hopefully, this helps the developers pinpoint the root cause!

[Jens Steidl]

Hi ,

just for clarification, did you use a development branch? AFAIK version 1.19 had no release or release candidate yet.

Best regards,

Jens Steidl
team member SLUBArchiv.digital | digital long-term preservation
Saxon State and University Library Dresden (SLUB)

[Julie S]

Hello,

Just chiming in to say that we've observed this behavior in AM 1.16.x as well. I see that an explanation for the issue was added in GitHub: https://github.com/archivematica/Issues/issues/1771

A solution other than downloading the AIP and ingesting with updated metadata from scratch would be wonderful!

Best,

Julie

Scholars Portal