Tengo dos cosas que abordar a continuación: La primera es que el límite es útil, pero solo aplica al espacio de búsqueda; a continuación, quiero poder especificar un número máximo de publicaciones a modificar. Por lo tanto, agregaré un número máximo de publicaciones a modificar, así como un límite para la consulta.
Además, al especificar max, tiene sentido ser explícito sobre lo que se está procesando con fines de depuración, por lo que me gustaría hacer que la salida sea detallada si max no es nil. Esto permitirá a las personas validar el proceso antes de continuar, ya que ese es el caso de uso principal de este trabajo.
Creo que lo que haré es especificar max como el primer argumento y un límite opcional como el segundo, porque realmente lo más importante es el máximo; el límite solo sirve para hacer que “un solo ping” sea más económico.
La segunda cuestión son las subidas no relacionadas con la migración. Hace algo más de un año, intenté subir un video al sitio de Discourse al que me estaba uniéndome, mientras luchaba por entender cómo escribir la migración desde Google+ a Discourse, y vi que lo que se había escrito era https://#{SiteSettings.absolute_base_url}/original/3X/b/a/ba9e06ebc2f4397f26793bb5cd4e169308dd371d.mp4.
Hoy, cuando subo un video, obtengo algo como  en su lugar.
Al menos en mi prueba más reciente, migrate_from_s3 distorsionó por completo esas URLs, de modo que ya ni siquiera son URLs válidas, por lo que definitivamente eso necesita ser corregido. Luego, creo que esta tarea es poco probable que se encuentre en la práctica con , así que como primer paso, me gustaría simplemente agregar el markdown de enlace alrededor del protocolo mágico upload, en lugar de hacer que la expresión regular maneje ambos casos y, como resultado, sea aún más difícil de leer. Pero podría cambiar de opinión al respecto.
Parece que la etiqueta video o audio se agrega en JavaScript mediante una coincidencia de expresión regular, por lo que tendré que copiar las expresiones regulares desde app/assets/javascripts/discourse/app/lib/uploads.js hacia la tarea para identificarlas correctamente. Incluiré el origen de las expresiones regulares para que la siguiente persona que las encuentre sepa dónde actualizarlas. 
…
Esta noche, encontré tiempo para trabajar en esto y tengo un borrador de PR en marcha. Aún no está terminado; sé que quedan errores en él. No creo que haya cambiado ningún comportamiento para las URLs del pseudo-protocolo upload: (normales para imágenes) en este punto, aunque agregué una verificación de coherencia.
Con los cambios en este PR, he migrado con éxito tanto las subidas normales del pseudo-protocolo upload: como los videos que actualmente se referencian explícitamente por referencia a S3 (en mi caso, espacios de Digital Ocean). Estoy usando esto para modificar solo una publicación a la vez con este comando:
bin/rake uploads:batch_migrate_from_s3[1,1000]
Tenga en cuenta que esto no irá más allá de las primeras 1000 publicaciones devueltas de manera algo aleatoria desde la consulta de la base de datos; el límite bajo es solo para acelerar la consulta mientras se migra una sola publicación a la vez, se revisa esa publicación para verificar su comportamiento correcto y luego se comienza de nuevo para encontrar otra. ¡Este comando funciona de esta manera solo con el PR en el que estoy trabajando actualmente!
…
Sigo agregando salida de diagnóstico mientras trabajo en esto, y estoy empezando a pensar que es importante no solo para el desarrollo. Estoy viendo muchas fallas de descarga transitorias desde los espacios de Digital Ocean, donde algunas, pero no todas, las descargas en una publicación se migran, lo cual, en el original, simplemente imprimiría un . y continuaría, y luego diría Done, pero en realidad la tarea no habrá terminado. Tuve que hacer algo como cinco o seis pasadas en una publicación antes de que se migraran todos los archivos. (No estaba contando porque pensé que al principio estaba depurando un error local). Espero tener que ejecutar esta migración repetidamente con el mismo límite hasta que los diagnósticos estén limpios. Por lo tanto, haré que la impresión de progreso detallada solo ocurra si max está establecido, pero imprimiré mensajes de advertencia útiles en cualquier caso.
Actualmente, estoy usando el siguiente truco para las descargas intermitentes que fallan en Discourse Spaces, lo cual, en la práctica, ha mejorado enormemente mi tasa de éxito (3 reintentos han sido totalmente suficientes en cientos de publicaciones migradas hasta ahora).
https://github.com/johnsonm/discourse/commit/7dfac12a2ea6ec04ba4e0616b4e0dbd1d806cff7
Además, descubrí que de alguna manera terminamos con videos más grandes que el límite que establecí cuando importé desde Google+. He tenido que aumentar temporalmente tanto SiteSettings.max_image_size_kb como SiteSettings.max_attachment_size_kb mientras realizaba migraciones puntuales de algunos videos demasiado grandes, de los cuales no tengo claro cómo terminaron en el sitio, pero no quiero romperlos ahora… No tengo idea si el error que permitió subidas demasiado grandes estaba en mi script de importación, en Discourse, o simplemente en mi memoria de los cambios que hice en la configuración con el tiempo. 
Como gran parte de lo que estoy migrando fue una importación desde G+, algunas de mis publicaciones terminaron fallando las validaciones actuales. Obtuvimos algunos Unhandled failure: Validation failed: Sorry, new users can only put one image in a post y al principio no entendí por qué no se repetían. Resulta que las subidas se movieron correctamente a local y todas usaban el pseudo-protocolo upload:, por lo que el contenido sin formato no cambió. Sin embargo, post.save! aún falló con ese error en las validaciones, lo que impidió que se ejecutara post.rebake!, por lo que tengo algunas publicaciones de 30K con imágenes que necesitan ser rebakeadas; lamentablemente, no tengo registro de cuáles son esas publicaciones. Ahora he cambiado a post.save!(validate: false) como otra solución, por lo que este problema en particular no debería volver a ocurrir. Estoy muy contento de haber hecho que la migración se detenga ante errores no manejados, de lo contrario, esto podría haber causado mucho más daño que algunas publicaciones.
…
Para mantener mi sitio usable, incluida la entrega de notificaciones, mientras ejecuto la migración, no quiero saturar las colas de Sidekiq. Sé que nombrar cosas es uno de los dos problemas más difíciles en la informática, junto con la invalidación de caché y los errores de “off-by-one”, pero propongo DISCOURSE_MIGRATION_MAX_ENQUEUED como variable de entorno para especificar cuántos espacios de cola totales (no espacios de trabajos) se permiten llenar al proceder a migrar otro elemento después de un rebake durante una migración, para evitar saturar las colas, de modo que el sitio continúe funcionando. Tengo un parche que agrega esto, con un valor predeterminado de cero, para todas las rebakeadas por publicación en lib/tasks/uploads.rake. Estoy usando esto en mi migración de producción.