Eine knifflige Frage. Ich habe s3_bucket in config/discourse.conf wie im von dir verlinkten Beitrag erwähnt gesetzt, was diesen spezifischen Fehler behoben hat, wie ich dort auch festgehalten habe.
Diese Datei befindet sich innerhalb des Containers (./launcher enter app). Beachte, dass du für die Beständigkeit nach einem ./launcher rebuild app auch DISCOURSE_S3_BUCKET im env-Abschnitt deiner containers/app.yml-Datei hinzufügen musst.
Der Grund, warum ich das als Entwickler-Beitrag und nicht als Support-Anfrage gepostet habe, war, dass ich es bereits behoben hatte; ich wollte wissen, was Entwickler als die richtige Lösung betrachten, während ich weiterhin daran feile.
Da ich etwa 100 GB Dateien in S3 habe, gehe ich sehr vorsichtig vor. Ich habe ein Limit für die zu prüfenden Beiträge implementiert, und als Nächstes muss ich ein Limit für die zu ändernden Beiträge umsetzen. Ich versuche es Schritt für Schritt. Dass es sich dabei offenbar um selten genutzten Code handelt und ich diesen Fehler wiederholt gesehen habe, macht mir Sorgen wegen Code-Rot. Ich möchte nicht plötzlich meine gesamte Website aufgrund eines Fehlers verunstalten, und hier liegt die Gefahr, genau diesen Fehler zu machen.
-
Für
upload://-Uploads (bei mir bedeutet das nicht-Video-Uploads) scheint es bisher zu funktionieren. Ich arbeite einen nach dem anderen ab und überprüfe den betroffenen Beitrag, um sicherzustellen, dass alles korrekt funktioniert. -
Für Uploads, die nicht die
upload://-Syntax verwenden (bei mir bedeutet das meines Wissens nach Video-Uploads), bei denen ein direkter Verweis auf die URL in S3 steht, werden die URLs verfälscht. Das ist kein hartnäckiger Fehler, sobald ich herausgefunden habe, was ich genau ändern muss, aber das habe ich noch nicht getan. Das wird also wahrscheinlich einer der PRs sein, die ich bald einreichen werde.
Das ist für mich ein Projekt in meiner Freizeit, daher kann ich keine Zeitversprechen geben.