# Come si salvano i video generati con AI prima che scadano i link temporanei? > Tratta gli URL del provider come credenziali di trasferimento brevi, non come posizioni degli asset. Accoda il download appena il job termina, invia il flusso allo storage durevole, verifica dimensione, tipo e checksum e registra l'URI permanente prima di completare il job. # Come si salvano i video generati con AI prima che scadano i link temporanei? Una generazione completata non è un asset durevole finché i byte non esistono in uno storage sotto il tuo controllo. Molte API restituiscono URL firmati o temporanei progettati per il trasferimento, non per la riproduzione a lungo termine. Salvare solo l'URL può far sparire un video approvato dopo ore o giorni. Crea una fase di ingestione separata che inizi al completamento. Reclama un'attività di download, ottiene un URL corrente, trasmette il media a un oggetto temporaneo, lo valida e lo promuove a una chiave permanente deterministica. Solo allora il job diventa completo. ## Tratta l'URL come una credenziale Un URL firmato spesso concede accesso temporaneo senza un altro header di autorizzazione, quindi è sensibile. Non esporlo in analytics, log visibili ai clienti, ticket o campi permanenti senza controlli rigorosi. Conserva invece: * ID del job del provider; * ID dell'output, se disponibile; * ora di emissione e scadenza osservata; * record dei tentativi di download; * chiave finale dello storage; * metadati di verifica e checksum. Se il provider indica la scadenza, pianifica il primo download con largo anticipo. Se non pubblica la durata, considera il link effimero e accoda subito il trasferimento. ## Separa generazione e ingestione dell'asset Completamento della generazione e salvataggio durevole sono stati diversi. Il job può riuscire da remoto e fallire localmente nel download. | Stato | Significato | Prossima azione | |---|---|---| | `generating` | Il provider crea il video | Polling o webhook | | `output_ready` | Output completato | Accoda il download | | `downloading` | Un worker possiede il trasferimento | Trasmetti allo storage temporaneo | | `verifying` | I byte sono arrivati | Ispeziona e calcola checksum | | `stored` | Oggetto durevole confermato | Salva l'URI permanente | | `complete` | Metadati e asset confermati | Consegna | | `download_retry` | Errore temporaneo | Aggiorna URL e ritenta | | `needs_attention` | Recupero automatico impossibile | Escalation con prove | Non segnare completo in `output_ready`. Questa scorciatoia è il motivo principale per cui i sistemi scoprono in seguito link scaduti. ## Conferma i webhook prima del download L'handler deve validare e salvare l'evento, accodare l'output e rispondere rapidamente. Scaricare un video grande dentro la richiesta rischia timeout e consegne ripetute. Deduplica per ID evento o combinazione di job e output. Rendi idempotente l'accodamento: ```text download_key = provider + provider_job_id + output_id ``` Webhook ripetuti convergono su un'attività. Polling e webhook possono chiamare la stessa `ensure_download_task`. ## Trasmetti a un oggetto temporaneo Evita di leggere tutta la risposta in memoria. Trasmetti blocchi a un file temporaneo o upload multipart mentre calcoli un checksum crittografico. Sequenza sicura: 1. Reclama l'attività con una lease a scadenza. 2. Ottieni un URL fresco se l'API lo consente. 3. Invia con timeout di connessione e lettura limitati. 4. Rifiuta redirect verso host inattesi. 5. Trasmetti i blocchi contando byte e SHA-256. 6. Chiudi e finalizza l'oggetto temporaneo. 7. Valida il media. 8. Promuovi o copia alla chiave finale. 9. Conferma URI e metadati. Usa backpressure per non accumulare più velocemente dello storage. Limita i trasferimenti per banda, dimensione e capacità, non solo per numero di job. ## Valida i byte, non solo gli header Un HTTP `200` può contenere HTML, JSON o un file troncato. `Content-Type: video/mp4` è un indizio, non una prova. | Validazione | Errore rilevato | |---|---| | Byte non nulli | Risposta vuota | | Lunghezza plausibile | Trasferimento troncato | | Firma del file | HTML o JSON salvato come video | | Analisi container | Struttura corrotta | | Durata maggiore di zero | Video incompleto | | Dimensioni e codec | Output fuori contratto | | SHA-256 | Byte cambiati o duplicati | | Decodifica campione | Media analizzabile ma non riproducibile | Salva i metadati osservati accanto all'oggetto. Confronta durata e risoluzione con tolleranze appropriate. Non rifiutare un video valido per pochi fotogrammi di differenza, se il contratto non richiede precisione assoluta. ## Usa chiavi durevoli deterministiche Una chiave prevedibile rende i retry idempotenti e gli asset tracciabili. Includi identità commerciale, variante e versione o checksum. ```text videos/{account}/{operation_id}/{attempt_id}/{output_id}-{sha256_prefix}.mp4 ``` Scrivi prima nello spazio temporaneo. Dopo la verifica promuovi l'oggetto o conferma un puntatore alla chiave per checksum. Se un altro worker ha già salvato lo stesso checksum per la stessa attività, riusalo. Non inserire nomi forniti dall'utente nei percorsi senza sanitizzazione. Conserva il nome originale nei metadati. ## Recupera da scadenze e trasferimenti interrotti Classifica gli errori: * reset di connessione e storage temporaneo possono ritentare con backoff; * autorizzazione o scadenza possono richiedere un nuovo URL; * not found può indicare che il provider ha eliminato l'asset; * checksum o validazione ripetutamente errati devono fermare i retry; * quota o permessi locali richiedono azione operativa, non un'altra chiamata. Conserva l'ID del job. Molte API possono generare un nuovo URL per un job completo anche dopo la scadenza del primo. Verifica questo comportamento sull'endpoint corrente. Riprendi un download parziale solo se origine e destinazione supportano range verificati e l'identità dell'oggetto non è cambiata. Altrimenti riavvia in un nuovo oggetto temporaneo: combinare versioni può creare un file corrotto. ## Scegli un retry che rispetti la scadenza Il backoff esponenziale può attendere oltre la vita del link. Limita il ritardo con la scadenza nota. ```text prossimo ritardo = min(backoff esponenziale, tempo alla scadenza - margine) ``` Se l'URL è vicino alla scadenza, aggiornalo prima. Usa jitter per evitare riconnessioni simultanee. Imposta limiti separati per trasferimenti e aggiornamenti URL. ## Proteggi il percorso di storage L'oggetto permanente deve seguire la tua policy. Usa bucket privati, crittografia appropriata, credenziali limitate e URL di consegna brevi. Non copiare query string nei metadati: possono contenere firme. Oscura gli URL nei log o conserva solo host, hash del percorso, emissione e scadenza. Applica scansione o moderazione quando richiesto. Mantieni i confini tenant nelle chiavi e nei controlli, ma non affidarti ai nomi dei percorsi per l'autorizzazione. ## Crea policy di conservazione e derivati Durevole non significa eterno. | Classe asset | Considerazione | |---|---| | Master approvato | Contratto e costo di rigenerazione | | Derivato di consegna | Ricreabile dal master | | Generazione rifiutata | Breve finestra di audit o contestazione | | Upload temporaneo | Eliminazione automatica dopo verifica | | Proxy di revisione | Conserva fino all'approvazione | Registra stato e motivo di eliminazione. Per la riproducibilità conserva prompt, hash sorgenti, modello, parametri e diritti, sapendo che una generazione non deterministica potrebbe non ricreare gli stessi byte. ## Monitora il tempo fino alla durabilità Misura l'intervallo tra completamento del provider e storage verificato: è la finestra in cui il link temporaneo è l'unica copia. Monitora output in attesa, età del più vecchio, percentili, risposte per URL scaduto, retry, URL aggiornati, errori di verifica, byte scaricati e job completi senza URI durevole. L'ultima metrica deve essere zero. Avvisa prima che il backlog si avvicini alla durata minima osservata. ## Mantieni chiare le responsabilità [Atlas Cloud](https://www.atlascloud.ai/?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=save-ai-videos-before-download-links-expire) può fornire una piattaforma compatibile con OpenAI per testo, immagini e video. Una piattaforma unica semplifica metadati e fatturazione, ma l'app resta responsabile di copiare gli output in uno storage conforme ai requisiti. Verifica il comportamento esatto di output e aggiornamento URL del modello corrente. Non inventare una scadenza né presumere lo stesso meccanismo per ogni modello. Esprimi le differenze come configurazione e controlli di capacità. ## In sintesi Salva i video trattando gli URL temporanei come credenziali di trasferimento in scadenza. Accoda il download subito, trasmetti a un oggetto temporaneo, valida il media e promuovilo a una chiave durevole. Registra URI e checksum prima di completare il job e progetta aggiornamenti, retry, conservazione e monitoraggio affinché la scadenza del link non porti via l'unica copia. ## FAQ ### Posso salvare l'URL di download come posizione finale del video? No. Gli URL firmati o temporanei possono scadere, essere revocati o cambiare. Salva la chiave dell'oggetto e l'ID del job e richiedi un URL fresco solo quando serve. ### Il worker dovrebbe caricare tutto il video in memoria? In genere no. Trasmetti la risposta a un file temporaneo o upload multipart mentre calcoli un checksum, così i file grandi non esauriscono la memoria. ### Che cosa va verificato prima di segnare un video come salvato? Verifica risposta HTTP, lunghezza se disponibile, firma del file, container, durata non nulla, requisiti di dimensione o codec, checksum e scrittura riuscita nello storage. ### Che cosa accade se l'URL scade durante il download? Conserva job e ID remoto, elimina o isola l'oggetto incompleto, richiedi un URL fresco se possibile e riprendi o riavvia secondo il supporto verificato dei range. ### Per quanto tempo conservare i video originali? Definisci la conservazione in base a esigenze cliente, legge, privacy, costo di rigenerazione e budget. Usa policy del ciclo di vita invece di dipendere dagli URL. ### Un webhook può scaricare direttamente il video? Il webhook dovrebbe rispondere rapidamente e accodare un download. Un worker separato può ritentare, verificare l'asset ed evitare di perdere eventi per trasferimenti lunghi.