Kann Avatare nicht hochladen mit aktiviertem S3 Storage (Datei vorhanden, schlägt trotzdem fehl)

Unterstützung
1

Hallo zusammen,

ich habe ein seltsames Problem mit Discourse + S3-Speicher.

Beim Hochladen von Avataren erhalte ich eine Fehlermeldung wie die untenstehende – obwohl die Datei vorhanden im S3-Bucket ist und über eine gültige s3_cdn_url erreichbar ist.

Uploads für Beiträge und Anhänge funktionieren einwandfrei. Das Einzige, was fehlschlägt, sind Benutzeravatar-Uploads.

:fire: Fehlermeldung von gig.ovh/logs


Nachricht (2 Kopien gemeldet)

Datei im Speicher unter der URL nicht gefunden: //gig.s3.ru-1.storage.selcloud.ru/original/1X/fd42dfa3362b66090450f2ae40f0917193fcd355.jpeg

Backtrace

/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active\ _support/broadcast\ _logger.rb:134:in `block in error'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `block in dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active\ _support/broadcast\ _logger.rb:231:in `each'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active_support/broadcast_logger.rb:231:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activesupport-7.2.2.1/lib/active\ _support/broadcast\ _logger.rb:134:in `error'
/var/www/discourse/app/models/optimized_image.rb:91:in `block in create\ _for'
/var/www/discourse/app/models/optimized\ _image.rb:19:in `block (2 levels) in lock'
/var/www/discourse/lib/distributed_mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed\ _mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed\ _mutex.rb:34:in `synchronize'
/var/www/discourse/app/models/optimized_image.rb:19:in `block in lock'
/var/www/discourse/lib/distributed\ _mutex.rb:53:in `block in synchronize'
/var/www/discourse/lib/distributed_mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed\ _mutex.rb:49:in `synchronize'
/var/www/discourse/lib/distributed_mutex.rb:34:in `synchronize'
/var/www/discourse/app/models/optimized\ _image.rb:18:in `lock'
/var/www/discourse/app/models/optimized_image.rb:83:in `create\ _for'
/var/www/discourse/app/models/upload.rb:151:in `get_optimized_image'
/var/www/discourse/app/controllers/user_avatars_controller.rb:219:in `get\ _optimized\ _image'
/var/www/discourse/app/controllers/user\ _avatars_controller.rb:137:in `show_in_site'
/var/www/discourse/app/controllers/user_avatars_controller.rb:90:in `block (2 levels) in show'
/var/www/discourse/lib/hijack.rb:68:in `instance_eval'
/var/www/discourse/lib/hijack.rb:68:in `block (2 levels) in hijack'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/i18n-1.14.7/lib/i18n.rb:353:in `with_locale'
/var/www/discourse/lib/hijack.rb:68:in `block in hijack'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:911:in `callback_on_resolution'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:797:in `call\ _callback'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:803:in `call_callbacks'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:692:in `resolve\ _with'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/concurrent-ruby-1.3.5/lib/concurrent-ruby/concurrent/promises.rb:1325:in `resolve'
/var/www/discourse/lib/scheduler/defer.rb:125:in `block in do\ _work'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails\ _multisite-6.1.0/lib/rails\ _multisite/connection\ _management/null\ _instance.rb:49:in `with_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-6.1.0/lib/rails_multisite/connection_management.rb:21:in `with\ _connection'
/var/www/discourse/lib/scheduler/defer.rb:119:in `do_work'
/var/www/discourse/lib/scheduler/defer.rb:105:in `block (2 levels) in start\ _thread'

Das ist eine S3-URL für den Container

//gig.s3.ru-1.storage.selcloud.ru/original/1X/fd42dfa3362b66090450f2ae40f0917193fcd355.jpeg

Das Bild ist unter der URL verfügbar:

https://s3.gig.ovh/original/1X/fd42dfa3362b66090450f2ae40f0917193fcd355.jpeg

:white_check_mark: Zusätzliche Informationen

  • Discourse-Version: (aktuellste stabile)
  • Externer S3-kompatibler Speicher verwendet (enable_s3_uploads = true)
  • s3_cdn_url ist korrekt konfiguriert und wird verwendet
  • CDN-URL gibt die Datei erfolgreich zurück
  • Datei ist vorhanden am erwarteten S3-Speicherort
  • Andere Uploads (Bilder, Anhänge usw.) funktionieren einwandfrei
  • Der Fehler tritt nur bei Benutzeravataren auf

:red_question_mark:Frage

Was könnte dazu führen, dass Discourse die Datei für die Avatarverarbeitung nicht abrufen kann, obwohl die exakte Datei existiert und über die korrekte CDN-URL erreichbar ist?

Gibt es etwas Spezifisches bei der Avatarverarbeitung (wie get_optimized_image), das falsch konfiguriert oder falsch gecacht sein könnte?

Jeder Vorschlag oder Einblick wäre willkommen!

Danke :folded_hands:

1 „Gefällt mir“
2

Hallo – hast du das jemals gelöst?

Ich stoße auf genau dasselbe Symptom bei Discourse + S3 (nur Avatare):
Could not find file in the store located at url: //<bucket>.s3.dualstack.<region>.amazonaws.com/original/1X/<hash>.jpeg

Ein paar Details zu meinem Setup, falls es mit deinem übereinstimmt:

  • enable_s3_uploads = true, Objekte befinden sich unter original/* und optimized/* (kein uploads/default-Präfix)

  • Zugriff über CloudFront (OAC), der Bucket selbst ist privat

  • Das Objekt existiert unter diesem Schlüssel; die CDN-URL funktioniert

  • Der Fehler tritt nur bei der Avatarverarbeitung auf

  • (Mögliches Problem) Uploads sind mit SSE-KMS verschlüsselt

Wenn du die Ursache oder eine Lösung gefunden hast (Richtlinienänderung, KMS-Berechtigungen, Ausrichtung des Bucket-Pfads usw.), könntest du bitte mitteilen, was funktioniert hat? Danke!