Quindi è confermato che il problema era che alcuni anni fa, quando ho provato per la prima volta a configurare S3, ho impostato enable_s3_uploads nel database, il che causa il fallimento del ripristino perché tenta di caricare su S3 ma non ha abbastanza informazioni. (Sospirando. Ma fallisce nel ripristinare l’istanza multisite/s3 perché alcuni file “non sono stati migrati su s3”.)
Mi chiedo se avrebbe senso nascondere tutte le impostazioni di caricamento S3. Sono abbastanza sicuro che non possa derivare nulla di buono dall’impostarle nell’UX. Ma può essere utile impostare i caricamenti S3 nel database. . . . forse.
Quello ripristinato all’installazione standard non riesce a mostrare i caricamenti perché sta facendo questo:
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)
Il percorso che sta cercando è /var/www/discourse/public/default/original/1X/ invece di /var/www/discourse/public/uploads/default/original/1X/
… . .
Ed è perché ho fatto una rimappatura cercando di correggere i riferimenti al bucket S3 e questo ha rotto i percorsi negli URL locali.
Penso che forse questo sia troppo nei dettagli per essere utile a qualcuno. Anche se penso ancora che nascondere le variabili di caricamento S3 dall’UX sia una buona idea.