# How Release Correction is handled

## Overview
Release Correction is utilised in the ingestion process to allow incremental updates to a product that is already approved by content managers and has a status of Complete.

*Note, Video is not supported by release correction.*

## What is covered by Release Correction
Release collection will include all fields updateable for all products set for distribution (`NFD = N`) except anything listed as limitations below.

## What is not covered by Release Correction
There are many fields not being covered by Release Correction, these include Product _Basics_ fields such as:
 ```
 Note that this list is only complete for products where not_for_distribution `NDF!= N` and we may see different functionality for `NDF` products
 ```

- Product Name          _(Includes label manager email - see 'Other considerations')_
- Product Version       _(Includes label manager email - see 'Other considerations')_
- Primary Artists(s)    _(Includes label manager email - see 'Other considerations')_
- Featured Artist(s)    _(Includes label manager email - see 'Other considerations')_
- Remixer(s)            _(Includes label manager email - see 'Other considerations')_
- Producer              _(Includes label manager email - see 'Other considerations')_
- Composer              _(Includes label manager email - see 'Other considerations')_
- Orchestra             _(Includes label manager email - see 'Other considerations')_
- Ensemble              _(Includes label manager email - see 'Other considerations')_
- Conductor             _(Includes label manager email - see 'Other considerations')_
- Genre                 _(Includes label manager email - see 'Other considerations')_
- Subgenre              _(Includes label manager email - see 'Other considerations')_
- Metadata Language
- Imprint
- (c) Line
- Localized Language> Product Name Correction
- Localized Language> Product VersioCorrection
- Localized Language> Primary ArtistCorrection
- Localized Language>Featured ArtistCorrection
- Localized Language> Remixer
- Localized Language> Producer


## Other considerations
We currently have some fields that can be Release Corrected that are not covered sufficiently within the UI to give the user clarity on what has changed, (e.g. Carveout Territories) and so it is useful for some types of updates to be communicated to label managers via email.

Additionally, it must be kept in mind that Release Corrections must be submitted and so are liable to the same breaks in ingestion flow that `label_processing` are subject to. That is, an update my fail to submit and so be left in an incomplete state. 

Users must be kept fully up to date with this and so emails are necessary to be provided in order to cover this eventuality and provide a sufficient feedback loop.

## Design decisions
During ingestion, it is sometimes necessary for some lambdas to be aware if a product is in Release Correction or not, this is important to handle code branching and other key processing decisions within the lambda itself.

When processing a product, it is necessary to enter a product into the Release Correction process and create a `ReleaseCorrection` as well as `ReleaseCorrectionDetail` for said product. If such a state is not created soon enough, it is possible for unintended side effects to occur.

One example of side effects is within audio asset handling; if a product has no `ReleaseCorrectionDetail` at ingestion time, the OWS assets service will fail to validate and ingestion will not complete successfully.

For this and other practicality reasons, it is necessary to handle the Release Correction process at multiple stages. These will be broken up such that one lambda is responsible for creating the initial Release Correction state - a `Release Correction lambda` will be created for this purpose - and each relevant lambda will handle their own `ReleaseCorrectionDetail` entries.

### Pros
- This allows timely handling of Release Correction within each lambda without significant rework to the structure of the State Machine
- We do not tie the creation of `ReleaseCorrection` to an existing lambda with its own responsibilities
- Only a lightweight Release Correction lambda is necessary - no monolith with all necessary data is required.

### Cons
- Release Correction code is handled in multiple places - leading to more code fragmentation.


As a GraphQL reference, a Release Correction is defined like so:

```
type ReleaseCorrection {
    releaseCorrectionId: Int!
    releaseId: Int!
    status: String!
    items: [ReleaseCorrectionDetail!]!
}
```

A ReleaseCorrectionDetail is so defined:


```
type ReleaseCorrectionDetail {
    releaseCorrectionDetailId: Int!
    tableName: String!
    fieldName: String!
    keyId: Int!
    keyValue: String!
}
```