Así que está confirmado que el problema fue que hace algunos años, cuando intenté configurar S3 por primera vez, establecí enable_s3_uploads en la base de datos, lo que provoca que la restauración no funcione porque intenta cargar en S3 pero no tiene suficiente información. (Suspiro. Pero falla al restaurar la instancia multisitio/s3 porque algunos archivos “no se migran a s3”).
Me pregunto si tendría sentido ocultar todas las configuraciones de carga de S3. Estoy bastante seguro de que no puede salir nada bueno de establecerlas en la UX. Pero puede ser útil establecer las cargas de S3 en la base de datos. . . . tal vez.
La que se restauró en la instalación estándar no muestra las cargas porque está haciendo esto:
Started GET "/uploads/short-url/puhaSNHeEy1S2knGFQIAZ8lprRy.pdf" for 68.11.35.109 at 2022-01-25 19:48:06 +0000
Processing by UploadsController#show_short as PDF
Parameters: {"base62"=>"puhaSNHeEy1S2knGFQIAZ8lprRy", "extension"=>"pdf"}
Sent file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830b.pdf (4.4ms)
Completed 500 Internal Server Error in 130ms (ActiveRecord: 0.0ms | Allocations: 10019)
ActionController::MissingFile (Cannot read file /var/www/discourse/public/default/original/1X/b2a283b9381b837234e7d4830.pdf)
La ruta que está buscando es /var/www/discourse/public/default/original/1X/ en lugar de /var/www/discourse/public/uploads/default/original/1X/
… . .
Y eso se debe a que hice una reasignación intentando arreglar las referencias del bucket S3 y eso rompió las rutas en las URL locales.
Creo que tal vez esto sea demasiado detallado para ser útil para alguien. Aunque sigo pensando que ocultar las variables de carga de S3 de la UX es una buena idea.