FEAT: Update Status Of Video Row On Media Convert Update

This commit is contained in:
FahdShalhoub
2026-08-27 20:04:38 +03:00
parent 5d35d4029e
commit 3f5301afb6
25 changed files with 1444 additions and 14 deletions
+44
View File
@@ -0,0 +1,44 @@
Feature: Transcoding status
A registered video starts life as "processing" and is handed to MediaConvert.
MediaConvert reports every job state change to an SNS topic, which fans the
event out to a queue cms consumes, so the catalogue record catches up with
the transcoding job on its own — nobody polls AWS and nothing is exposed for
AWS to call back into.
Background:
Given the CMS API is available
Scenario: A finished job marks the video ready
Given I have registered a video that is being transcoded
When MediaConvert reports that the job reached "COMPLETE"
Then the video eventually has status "ready"
Scenario Outline: A job that did not finish cleanly marks the video failed
Given I have registered a video that is being transcoded
When MediaConvert reports that the job reached "<state>"
Then the video eventually has status "failed"
Examples:
| state |
| ERROR |
| CANCELED |
Scenario Outline: A state that is not an outcome leaves the video processing
Given I have registered a video that is being transcoded
When MediaConvert reports that the job reached "<state>"
Then the video keeps status "processing"
Examples:
| state |
| SUBMITTED |
| PROGRESSING |
| STATUS_UPDATE |
# A message naming a job nobody has must be consumed and dropped, not left to
# redeliver forever. The second event is the assertion that it was: it can
# only be handled if the first one did not wedge the consumer.
Scenario: An event for a job no video has does not stop the consumer
Given I have registered a video that is being transcoded
When MediaConvert reports that the job "1700000000000-nosuchjob" reached "COMPLETE"
And MediaConvert reports that the job reached "COMPLETE"
Then the video eventually has status "ready"
+52
View File
@@ -0,0 +1,52 @@
Feature: Video details
A registered video can be read back by its id. This is how a client learns
what became of an upload once it was handed to the transcoding pipeline —
without it, the status a video carries is written but never visible.
Background:
Given the CMS API is available
Scenario: Reading back a video that was registered
Given I have requested an upload slot for "detail.mp4" of type "video/mp4"
And I have uploaded the file to the upload URL
And I have registered the uploaded video titled "Inside the Newsroom" under categories "documentary, news"
When I ask the CMS for that video
Then the request succeeds with status 200
And the video has an id
And the video is registered with status "processing"
And the video is stored under the key from the upload slot
And the video is filed under categories "documentary, news"
And the video keeps the metadata I sent
# A uuid has several accepted spellings, and Postgres takes only some of them
# verbatim — the urn form it rejects outright. The handler parses the id and
# queries with the canonical form, so every spelling names the same video
# instead of some of them faulting.
Scenario Outline: Reading a video by another accepted spelling of its id
Given I have registered a video
When I ask the CMS for that video with its id written <form>
Then the request succeeds with status 200
And the video has an id
Examples:
| form |
| braced |
| unhyphenated |
| as a urn |
Scenario: Asking for a video that does not exist
When I ask the CMS for the video with id "0199f3a1-7c2e-7b21-9f0d-1a2b3c4d5e6f"
Then the request is rejected with status 404
And the problem title is "Video Not Found"
Scenario Outline: Asking for a video with an id that is not a video id
When I ask the CMS for the video with id "<id>"
Then the request is rejected with status 404
And the problem title is "Video Not Found"
Examples:
| id |
| not-a-uuid |
| 12345 |
| 0199f3a1-7c2e-7b21-9f0d-1a2b3c4d5e6 |
| '; DROP TABLE videos; -- |