AIP–DIP relation (related_packages) missing when DIP is created via partial reingest (API)

[Thales Oliveira Torres Brasil]

Hi all,

I’m seeing an inconsistent behaviour in Archivematica 1.19 regarding the relation between AIPs and DIPs when the DIP is created via partial reingest (normalize for access). When the DIP is created during the original ingest (normalize for: preservation and access), the related_packages field on the AIP record is correctly populated with the DIP identifier. However, when the DIP is created later via partial reingest, this relation is not created, and it seems to be lost in both directions (AIP → DIP and DIP → AIP).

Expected behaviour (works on ingest)

If I run an ingest with “Normalize for: preservation and access”, the API behaves as expected. An AIP is generated, a DIP is created during ingest, and when I query:

GET /api/v2/file/<aip-uuid>/

the response includes the DIP inside related_packages. Example (real output, trimmed):

{ 

  "package_type": "AIP", "resource_uri": "/api/v2/file/f1af0200-0261-4524-943b-77283d84adf3/",

  "uuid": "f1af0200-0261-4524-943b-77283d84adf3", 

  "related_packages": [ "/api/v2/file/5e91e36d-91c8-4c26-b60e-05e195b4469e/" ],

  "status": "UPLOADED", 

  "stored_date": "2025-11-01T11:48:04.611311" 

}

This is the expected and desired behaviour, because it allows discovering the DIP UUID from the AIP and downloading it via the API.

Problematic behaviour (partial reingest)

The issue happens when following the recommended workflow of normalizing only for preservation during ingest, and later generating a DIP via partial reingest using normalize for access. In my workflow:

1. I start the reingest with
   POST /api/v2/file/<aip-uuid>/reingest/

2. I provide a processing config that normalizes for access.

3. I approve the reingest with
   POST /api/ingest/reingest/approve

The reingest completes successfully and the DIP is indeed created. However, when I query the same AIP afterwards:

GET /api/v2/file/<aip-uuid>/

the field related_packages comes back empty. Example:

{ 

  "package_type": "AIP", "resource_uri": "/api/v2/file/3c967058-923d-4828-8505-9e3d11b2050b/",

  "uuid": "3c967058-923d-4828-8505-9e3d11b2050b",

  "related_packages": [], 

  "status": "UPLOADED", 

  "stored_date": "2025-11-25T16:19:43.708103"

}

In this situation, the AIP does not list the DIP in related_packages, the DIP does not list the AIP either, and the package-listing endpoints do not expose any way to discover which DIP belongs to that AIP. So there is no method to programmatically retrieve or download the DIP generated via partial reingest.

Additional observation (existing relation is lost on reingest)

There is another issue: if the AIP originally had a DIP created during ingest (so the relation existed), performing a partial reingest to generate a new DIP removes the old relation, but also does not create a new relation for the newly generated DIP. The result is:

related_packages: []

even though a new DIP was created successfully. Since related_packages is an array, I would expect Archivematica to either store both DIP IDs or replace the old one with the new. Instead, the field is cleared and not repopulated.

Impact

This prevents automated workflows from tracking or downloading DIPs created via partial reingest. It also contradicts the recommendation in the documentation to normalize for preservation during ingest and generate access copies later via partial reingest.

Questions

• Is this a known issue/bug or limitation in Archivematica 1.19?

• Is there any other endpoint or recommended method to obtain the DIP UUID from an AIP when the DIP is created via partial reingest? Listing all DIPs with api/v2/file/?package_type=DIP is not viable, since the AIP–DIP relation does not exist in this scenario. Even though the AIP UUID appears at the end of the DIP’s current_full_path, parsing thousands of records to extract that value is not scalable. Ideally, it should be possible to retrieve the DIP UUID directly from the AIP in a clear 1:1 relation.

I can provide more logs, full JSON responses, or run additional tests if needed.

[Sarah Mason]

Thank you for posting your issue, I hope that other users have some feedback or comments for you. I spoke to the project maintainers about this and we agree it is worth filing this issue in GitHub as it is currently not listed. You've provided a lot of clear detail that points to an issue that hasn't been filed. It is likely related to the issue you previously filed so it is worth articulating a new one.

I also just want to confirm. Are you testing in with the current stable version (1.18.x) or the QA (future 1.19) version? Just for testing purposes I wanted to confirm.

Thanks,

Sarah Mason

Contributor Success Specialist

[Thales Oliveira Torres Brasil]

Thank you for the follow-up. I appreciate the clarification, and yes — I will go ahead and open a new issue on GitHub with all the details.

To confirm, I’m running my tests on version 1.19.0.

Thanks again!