Ho due cose da affrontare di seguito: la prima è che il limite è utile ma si applica solo allo spazio di ricerca; successivamente voglio poter specificare un numero massimo di post da modificare. Quindi aggiungerò un numero massimo di post da modificare, oltre a un limite per la query.
Inoltre, quando si specifica max, ha senso essere espliciti su ciò che viene elaborato a scopo di debug, quindi vorrei rendere l’output verboso se max non è nil — questo permetterà agli utenti di validare il processo prima di procedere, dato che questo è il caso d’uso principale di questo lavoro.
Penso che specificherò max come primo argomento e un limite opzionale come secondo, perché in realtà max è la cosa più importante; il limite serve solo a rendere più economica l’esecuzione “un ping alla volta”.
La seconda cosa riguarda i non-upload: gli upload. Circa un anno fa, ho provato a caricare un video sul sito Discourse a cui stavo aderendo, mentre ero confuso nel cercare di capire come scrivere la migrazione da Google+ a Discourse, e ho visto che ciò che era stato scritto era https://#{SiteSettings.absolute_base_url}/original/3X/b/a/ba9e06ebc2f4397f26793bb5cd4e169308dd371d.mp4
Oggi, quando carico un video, ottengo qualcosa del tipo .
Almeno nel mio test più recente, migrate_from_s3 ha completamente storpiato quegli URL, rendendoli non più nemmeno degli URL validi, quindi questo va assolutamente corretto. Poi, penso che in pratica questo compito abbia poche probabilità di incontrare , quindi come primo approccio vorrei semplicemente aggiungere la sintassi markdown del link attorno al protocollo magico upload, piuttosto che far gestire entrambi i casi alla regex, rendendola di conseguenza ancora più difficile da leggere. Potrei però cambiare idea su questo punto.
Sembra che il tag video o audio venga aggiunto in JavaScript tramite una corrispondenza regex, quindi dovrò copiare le regex da app/assets/javascripts/discourse/app/lib/uploads.js all’interno del task per identificarle correttamente. Includerò l’origine delle regex in modo che la prossima persona che le trova sappia da dove aggiornarle. 
…
Stasera ho trovato un po’ di tempo per lavorare su questo e ho già una bozza di PR in corso. Non è ancora completata; so che ci sono ancora dei bug. Non credo di aver modificato alcun comportamento per gli URL del pseudo-protocollo upload: (normali per le immagini) fino a questo punto, anche se ho aggiunto un controllo di coerenza.
Con le modifiche in questa PR, ho migrato con successo sia i normali upload del pseudo-protocollo upload: che i video attualmente referenziati esplicitamente tramite S3 (nel mio caso, DigitalOcean Spaces). Sto usando questo per modificare un solo post alla volta con questo comando:
bin/rake uploads:batch_migrate_from_s3[1,1000]
Nota che questo non andrà oltre i primi 1000 post restituiti in modo piuttosto casuale dalla query al database; il limite basso serve solo per velocizzare la query mentre si migra un solo post alla volta, si verifica il corretto comportamento di quel post e poi si ricomincia per trovarne un altro. Questo comando funziona in questo modo solo con la PR su cui sto lavorando attualmente!
…
Continuo ad aggiungere output diagnostico mentre lavoro su questo, e sto iniziando a pensare che sia importante non solo per lo sviluppo. Sto riscontrando molti fallimenti temporanei di download da DigitalOcean Spaces, dove alcuni ma non tutti i download in un post vengono migrati, il che nell’originale stampa solo un . e continua, per poi dire Done, ma in realtà il task non sarà completato. Ho dovuto fare circa cinque o sei passate su un solo post prima che venissero migrati tutti i file. (Non stavo contando perché pensavo di stare debuggando un bug locale all’inizio.) Mi aspetto di dover eseguire questa migrazione ripetutamente con lo stesso limite finché i diagnostici non saranno puliti. Pertanto, sto rendendo la stampa verbosa del progresso attiva solo se max è impostato, ma stampando messaggi di avviso utili in ogni caso.
Al momento, sto usando questo hack per i download intermittenti falliti da Discourse Spaces, che nella pratica ha migliorato enormemente il mio tasso di successo (3 tentativi sono stati completamente sufficienti su centinaia di post migrati finora).
https://github.com/johnsonm/discourse/commit/7dfac12a2ea6ec04ba4e0616b4e0dbd1d806cff7
Inoltre, ho scoperto che in qualche modo siamo finiti con video più grandi del limite che avevo impostato quando ho importato da Google+ — ho dovuto aumentare temporaneamente sia SiteSettings.max_image_size_kb che SiteSettings.max_attachment_size_kb mentre facevo migrazioni one-shot di alcuni video troppo grandi, di cui non è chiaro come siano finiti sul sito, ma non voglio romperli ora… Non so se il bug che permetteva upload di dimensioni eccessive fosse nel mio script di importazione, in Discourse, o semplicemente nella mia memoria di quali modifiche ho apportato alle impostazioni nel tempo. 
Poiché gran parte di ciò che sto migrando proviene da un’importazione da G+, alcuni dei miei post hanno fallito le convalida attuali. Ho ricevuto alcuni errori Unhandled failure: Validation failed: Sorry, new users can only put one image in a post e inizialmente non ho capito perché non si ripetessero. Si è scoperto che gli upload sono stati spostati con successo in locale e tutti utilizzavano il pseudo-protocollo upload:, quindi il raw non è cambiato. Tuttavia, post.save! falliva comunque con quell’errore durante le convalide, impedendo a post.rebake! di essere eseguito, quindi ho alcuni post su 30K con immagini che devono essere ribakeati; purtroppo, non ho traccia di quali siano quei post. Ora sono passato a post.save!(validate: false) come altra soluzione, quindi questo particolare problema non dovrebbe ripetersi. Sono molto contento di aver fatto sì che la migrazione si interrompesse sugli errori non gestiti, altrimenti avrebbe potenzialmente causato molti più danni di qualche solo post.
…
Per mantenere il mio sito utilizzabile, inclusa la consegna delle notifiche, durante l’esecuzione della migrazione, non voglio intasare le code di Sidekiq. So che nominare le cose è uno dei due problemi più difficili nell’informatica, insieme all’invalidazione della cache e agli errori di off-by-one, ma propongo DISCOURSE_MIGRATION_MAX_ENQUEUED come variabile d’ambiente per indicare quanti slot totali della coda (non slot di lavoro) sono consentiti come riempiti quando si procede a migrare un altro elemento dopo un rebake durante una migrazione, per evitare di intasare le code, in modo che il sito continui a funzionare. Ho una patch che aggiunge questa funzionalità, con valore predefinito zero, per tutti i rebake per post in lib/tasks/uploads.rake. Sto usando questo nella mia migrazione di produzione.