Estoy intentando mover las cargas a s3 en un sitio relativamente ocupado.
Todo va según lo planeado, excepto cuando ejecuto rake uploads:migrate_to_s3, me encuentro con el siguiente error:
Actualizando las URLs en la base de datos...
Eliminando imágenes optimizadas antiguas...
Marcando todas las publicaciones que contienen lightboxes para volver a procesar...
Se marcaron 2023 publicaciones para volver a procesar
rake abortó!
FileStore::ToS3MigrationError: 1 de 9629 cargas no se migraron a S3. La migración a S3 falló para la base de datos 'default'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:132:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:79:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:373:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:66:in `migrate'
/var/www/discourse/lib/tasks/uploads.rake:123:in `migrate_to_s3'
/var/www/discourse/lib/tasks/uploads.rake:102:in `block in migrate_to_s3_all_sites'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:90:in `each_connection'
/var/www/discourse/lib/tasks/uploads.rake:100:in `migrate_to_s3_all_sites'
/var/www/discourse/lib/tasks/uploads.rake:96:in `block in <main>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => uploads:migrate_to_s3
(Ver el rastreo completo ejecutando la tarea con --trace)
Esta línea en particular llamó mi atención: FileStore::ToS3MigrationError: 1 de 9629 cargas no se migraron a S3. La migración a S3 falló para la base de datos 'default'.
Supongo que significa que hay un archivo problemático que está causando que toda la tarea rake falle. ¿Hay alguna forma de averiguar qué archivo está causando el problema y tal vez eliminarlo para que el resto de la tarea se complete sin problemas?
Actualización:\nEl sitio parece cargarse normalmente y, por lo que puedo ver, las imágenes subidas se sirven desde la CDN. La copia local de todas las subidas todavía existe en el servidor. Supongo que esto se debe a que la migración está marcada como fallida. ¿Es útil la siguiente salida de rake uploads:s3_migration_status de alguna manera?\n\n\n# rake uploads:s3_migration_status\n1 de 9630 subidas no se han migrado a S3. La migración a S3 falló para la base de datos 'default'.\n19 publicaciones no se han reasignado a la nueva URL de subida de S3. La migración a S3 falló para la base de datos 'default'.\nNinguna publicación requiere rebake\nEl sitio no está listo para la migración\n
Es posible que encuentres una referencia a qué archivo falló en Admin > Registros > Registros de errores.
Si eso no ayuda, creo que buscar en la base de datos publicaciones con cooked que contengan tudominio/uploads/ te dará una lista de esas 19 publicaciones mencionadas en el estado de la migración. En el peor de los casos, podrías revisarlas manualmente y comparar las cargas con lo que hay en S3.
Algo como:
rails c
Post.where("cooked like '%discourse.example.com/uploads/%'")
Probé tus sugerencias, lamentablemente, no tuve suerte encontrando nada relevante en los registros de errores. Veo una entrada como Failed to optimize image: unknown reason pero no me da más información de la que dice.
También probé tu consulta sugerida, obtengo un montón de publicaciones como resultado, pero al visitar esas publicaciones, contienen un montón de miniaturas de las vistas previas de onebox. Cuando intento abrir la imagen en una nueva pestaña en esas miniaturas, estas parecen cargarse desde la CDN.
Creo que esperaría ver algo así para 18 de esas 19 publicaciones, tal vez incluso las 19 si la carga fallida ocurre en una publicación con varias cargas.
Lo que podría ser más fácil es extraer todos los nombres de archivo del resultado de la consulta (por ejemplo, f8a2d9381889b8693db2777acac566bd7b134fa5.png) y buscarlos en S3. En teoría, solo faltaría uno. Ignora los derivados, solo busca los que tengan /originals/ en la ruta.
Un poco tedioso pero no debería llevar mucho tiempo si esa consulta solo seleccionó esas 19 publicaciones.
Si no hay una solución obvia para que se cargue correctamente, cualquiera de las opciones 1 o 3 parece una buena manera de proceder. La 2 probablemente la dejaría para Discourse, específicamente la tarea de limpiar las cargas huérfanas, cuyo intervalo se controla con la configuración clean orphan uploads grace period hours.
Sin embargo, podría ser una buena idea descargar el archivo antes de que se elimine. Si no contiene datos confidenciales, podría ser útil para probar por qué no se puede cargar durante la migración.
Algo más que podrías intentar después de haber eliminado el archivo y completado la migración (y haber descargado el archivo fallido) es editar la publicación nuevamente para volver a colocar el archivo. Sería interesante saber si falla al subir a S3 por completo o solo durante la tarea de migración.
Si no te importa perder esos 64 archivos, lo que hice cuando esta misma tarea de rake me fallaba es editarla y hacer que solo falle si hay 100 errores en lugar de 1.
Probado con SKIP_FAILED=100 rake uploads:migrate_to_s3
=> 0 archivos
Listando archivos de S3
… .. => 81070 archivos
Sincronizando archivos a S3
Actualizando las URL en la base de datos…
Eliminando imágenes optimizadas antiguas…
Marcando todas las publicaciones que contienen lightboxes para volver a hornear…
54453 publicaciones fueron marcadas para volver a hornear
53 publicaciones no se remapean a la nueva URL de carga de S3. La migración de S3 falló para la base de datos ‘default’.
No entendí cómo poner el archivo modificado en mi script de discourse
Ah, qué lástima. Está la otra sugerencia de @Falco de editar la tarea de rake, pero desafortunadamente no sé cómo hacerlo y no encuentro ninguna instrucción cuando busco.
