`ShipmentDependents` grows without bound in instance storage and is never purged

[dinahmaccodes]

Tier: Hard
Description: Unlike every other per-shipment index (notes, evidence, recovery records, status hashes) which live in persistent storage and are purged on archival, ShipmentDependents(dependent_id) (storage.rs:2190-2208) lives in instance storage and is entirely absent from archive_shipment's cleanup block. Instance storage is a single shared ledger entry across the whole contract, making unbounded growth here a scalability risk larger in impact than a comparable persistent-key leak.
Files: contracts/shipment/src/storage.rs:2190-2208
Tasks:

• Move ShipmentDependents to persistent storage and add it to archive_shipment's purge list
  Acceptance Criteria:
• ShipmentDependents entries are purged on archival and no longer inflate instance storage indefinitely

[deedee-code]

@deedee-code has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi maintainer, i will like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @deedee-code to this issue.

[aliyuzuliehat25]

@aliyuzuliehat25 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi, I’d like to work on this issue.

I’ll first trace how ShipmentDependents is written, read, updated, and consumed throughout the shipment contract, as well as how archive_shipment currently handles cleanup of other per-shipment storage.

Proposed approach

• Move ShipmentDependents from instance storage to persistent storage, following the existing patterns for per-shipment indexes.
• Update all read/write paths to use the new storage location consistently.
• Add ShipmentDependents to the archive_shipment cleanup/purge flow.
• Ensure archival removes all dependent entries associated with the shipment.
• Preserve existing public behavior and avoid unrelated storage refactors.
• Consider compatibility/migration implications for shipments created before the storage change and document the approach if migration handling is required.

Test strategy
I’ll add focused contract tests covering:

• Creating and retrieving shipment dependents after the storage change.
• Multiple dependents for a shipment.
• Updating/removing dependents where supported.
• Archiving a shipment and verifying its ShipmentDependents entries are purged.
• Confirming unrelated shipments’ dependent entries remain intact.
• Repeated archival/cleanup behavior.
• Regression coverage for existing dependent-related functionality.
• Storage behavior confirming the entries no longer remain in instance storage.

Validation
I’ll run the focused shipment contract tests, formatting/lint/build checks, and the complete applicable repository CI suite. I’ll also verify resource/storage implications where the repository provides tooling for this.

Estimate
I estimate 3–5 days for investigation, storage migration, updating access paths, archival testing, compatibility review, and validation.

I’ll wait for maintainer assignment before starting implementation.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @aliyuzuliehat25 to this issue.

[classikdev]

@classikdev has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

kindly please assign me to this issue thanks

ℹ️ Repo Maintainers: To accept this application, review their application or assign @classikdev to this issue.