After a number of changes to the FileStatus in both the Django app and the core API, the engineers discussed simplifying our approach so that the two types of status only contain information that is relevant for each application and to reduce the implicit dependency on each other.
Changes proposed in this pull request
Only use these file statuses in Django: processing, complete, errored, deleted, and move the core_api -> django FileStatus mapping to models.py. Update tests as required.
I have also set the file status to errored where there are problems communicating with the core-api, to avoid repeated broken requests. This may require us to offer the option to re-ingest errored files at another time.
Guidance to review
I've two questions about the approach:
Should we hold off setting the file status to errored in the case of non-404 errors from the core-api?
Is there a better approach to avoiding unexpected behaviours from new core-api statuses than just the comment I've added to redbox-core/redbox/models/file.py ?
Context
After a number of changes to the FileStatus in both the Django app and the core API, the engineers discussed simplifying our approach so that the two types of status only contain information that is relevant for each application and to reduce the implicit dependency on each other.
Changes proposed in this pull request
Only use these file statuses in Django:
processing,complete,errored,deleted, and move the core_api -> django FileStatus mapping tomodels.py. Update tests as required.I have also set the file status to
erroredwhere there are problems communicating with the core-api, to avoid repeated broken requests. This may require us to offer the option to re-ingest errored files at another time.Guidance to review
I've two questions about the approach:
erroredin the case of non-404 errors from the core-api?redbox-core/redbox/models/file.py?Relevant links
https://technologyprogramme.atlassian.net/browse/REDBOX-576
Things to check