Build the two timelines
An invented manifest advertises segment S at 12:00:00, but S becomes available at the origin at 12:00:02. A reader requests it in between and receives a 404. If that response is stored downstream, a later reader can still receive the earlier error after the upload has completed.
HTTP permits caching of some unsuccessful responses; RFC 9110 identifies 404 as heuristically cacheable unless other controls apply. Do not assume that an error response is automatically invisible to cache policy.
Compare the normal route with the release state
Keep the first error response, observation time and available cache information. Compare them with the upload-completion and manifest-publication records. A current successful origin response does not show what a reader received through an intermediary moments earlier.
Cache-Status, where implemented, can help explain cache handling. Its absence is not proof that no cache participated. Avoid inferring a particular provider's cache key or error lifetime from one header name without checking that deployment's documented behaviour.
Repair ordering before increasing retries
The preferred publication sequence is to make the intended media available before advertising its reference. Review error-response caching separately so a transient publishing mistake is not unnecessarily prolonged. A blanket cache purge may hide the symptom without fixing the release race.
After a change, define a controlled acceptance exercise on an owned test path. Include a deliberately unavailable resource and record its later availability through the normal route. This article proposes that exercise; it reports no actual origin or CDN test.
Questions answered
Does a 404 always mean the segment never existed?
No. It describes that response, and it may be stored or reflect a publication race.
Does uploading the file automatically remove an earlier cached 404?
Do not assume that. Review the error response's cache policy and the delivery system.
Sources & further reading
Official references for the subjects discussed. Service terms and device software can change.