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
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 "" 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; -- |