\u003e Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RecordInvalid: Validation failed: Post has already been taken
Wenn ich versuche, es erneut zu versuchen, schlägt es wieder fehl. Dies scheint sich auf ein neues Thema zu beziehen, das von einem Benutzer erstellt wurde.
Ich sehe, dass der Server eine Reihe von E-Mails erfolgreich für dieses neue Thema an alle gesendet hat, die diese Kategorie beobachtet haben. Ich sehe auch keine Fehler in den E-Mail-Protokollen oder auf dem E-Mail-Server.
Für diesen Eintrag ja, er hing immer noch in einer Wiederholungsschleife fest, bis gestern, als ich es nach Hunderten von Wiederholungen leid war und ihn löschte. Ich hoffe, ich habe nichts kaputt gemacht.
Ich habe es nicht wieder gesehen, aber dann gab es kein Ereignis, das Hunderte von E-Mails zu einem einzigen Beitrag auslöste. Es wäre jedoch schön zu verstehen, woher das kam und was es bedeutet.
Vor ein paar Tagen habe ich diese Fehlermeldung bei drei Nachrichten gesehen, und sie waren nicht kritisch, also habe ich die Jobs gelöscht, nachdem ein erneuter Versuch nicht erfolgreich war.
Jetzt habe ich 2001 davon, und mein Testkonto hat keinen wöchentlichen Digest erhalten, den es hätte erhalten sollen.
Ich habe auf bf987af3ca aktualisiert und alles erneut versucht, aber in meiner Sidekiq-Konsole werden immer noch mindestens 38 Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RecordInvalid: Validation failed: Post has already been taken angezeigt.
Ohne weitere Updates bin ich jetzt bei 30. Ich vermute, dass sie Zeitüberschreitungen haben, außer dass mein Testkonto den (verzögerten) wöchentlichen Digest erhalten hat, und ich nehme an, dass dies damit zusammenhängt. Ich bin mir nicht sicher, wo ich in den Protokollen nachsehen soll, um zu wissen, ob einige tatsächlich aufgeben.
Sie scheinen meistens zu scheitern, aber gelegentlich erfolgreich zu sein, was definitiv nach einer Race Condition irgendwo riecht.
Meine Backtraces sehen genauso aus wie die, die @RBoy und @md-misko gesehen haben, aber hier ist die vollständige Backtrace, nicht nur die abgeschnittene vom “Kopieren”-Button:
activerecord-7.0.3/lib/active_record/validations.rb:80:in `raise_validation_error'
activerecord-7.0.3/lib/active_record/validations.rb:53:in `save!'
activerecord-7.0.3/lib/active_record/transactions.rb:302:in `block in save!'
activerecord-7.0.3/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:314:in `transaction'
activerecord-7.0.3/lib/active_record/transactions.rb:350:in `with_transaction_returning_status'
activerecord-7.0.3/lib/active_record/transactions.rb:302:in `save!'
activerecord-7.0.3/lib/active_record/suppressor.rb:54:in `save!'
activerecord-7.0.3/lib/active_record/persistence.rb:55:in `create!'
activerecord-7.0.3/lib/active_record/relation.rb:869:in `_create!'
activerecord-7.0.3/lib/active_record/relation.rb:115:in `block in create!'
activerecord-7.0.3/lib/active_record/relation.rb:880:in `_scoping'
activerecord-7.0.3/lib/active_record/relation.rb:428:in `scoping'
activerecord-7.0.3/lib/active_record/relation.rb:115:in `create!'
activerecord-7.0.3/lib/active_record/relation.rb:219:in `block in create_or_find_by!'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
activesupport-7.0.3/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
activerecord-7.0.3/lib/active_record/connection_adapters/abstract/database_statements.rb:316:in `transaction'
activerecord-7.0.3/lib/active_record/transactions.rb:209:in `transaction'
activerecord-7.0.3/lib/active_record/relation.rb:67:in `block in transaction'
activerecord-7.0.3/lib/active_record/relation.rb:880:in `_scoping'
activerecord-7.0.3/lib/active_record/relation.rb:428:in `scoping'
activerecord-7.0.3/lib/active_record/relation.rb:67:in `transaction'
activerecord-7.0.3/lib/active_record/relation.rb:219:in `create_or_find_by!'
activerecord-7.0.3/lib/active_record/querying.rb:22:in `create_or_find_by!'
/var/www/discourse/lib/email/sender.rb:498:in `get_reply_key'
/var/www/discourse/lib/email/sender.rb:105:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:83:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:38:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
/var/www/discourse/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.4.2/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.4.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.4.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.4.2/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.4.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_retry.rb:114:in `local'
sidekiq-6.4.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq.rb:40:in `block in <module:Sidekiq>'
sidekiq-6.4.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.4.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.4.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_retry.rb:81:in `global'
sidekiq-6.4.2/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.4.2/lib/sidekiq/job_logger.rb:39:in `prepare'
sidekiq-6.4.2/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.4.2/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.4.2/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.4.2/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.4.2/lib/sidekiq/util.rb:56:in `watchdog'
sidekiq-6.4.2/lib/sidekiq/util.rb:65:in `block in safe_thread'
Gibt es noch weitere Informationen, die ich zur Fehlersuche bereitstellen könnte?
4 „Gefällt mir“
RGJ
(Richard - Communiteq)
Hat dieses Thema aufgeteilt,
16
Ich habe festgestellt, dass mein Mailserver in seiner Round-Robin-Konfiguration ein Zertifikat für einen anderen Server verwendete, und hoffte, dass die Nichtübereinstimmung des Hostnamens das Problem war. Ich habe im Zuge der Umstellung auf einen Server, der keine Zertifikatsabweichung aufwies, auf b850c12793 aktualisiert, aber das Problem wurde dadurch nicht behoben. Ich habe einige der Jobs erneut versucht, aber keiner von ihnen wurde erfolgreich abgeschlossen. Daher ist dieser Fehler kein Symptom versteckter Zertifikatsabweichungen.
Dies wurde mit discourse_docker 2a9faf7e5680b9 erstellt.
Das Aktualisieren von discourse_docker auf 241a42ce718 und damit discourse auf 95e7e10417 hat das Problem ebenfalls nicht behoben. Ich habe immer noch 30 dieser fehlgeschlagenen Versuche, die erneut versucht werden.
Basierend auf Ihrer Beschreibung und diesem Beitrag gibt es hier möglicherweise mehrere Probleme:
Der Server drosselt möglicherweise seine Wiederholungsversuche für E-Mails nicht, was dazu führt, dass diese abgebrochen oder vom Mailserver abgelehnt werden. Aber es gibt ein anderes zugrunde liegendes Problem, wenn Ihre Zertifikate und Ihre Konfiguration gültig sind und die E-Mails immer noch nicht gesendet werden. Bei einigen scheint es auch Speicherplatz zu verbrauchen. Ich habe meinen überprüft, aber das ist mir hier nicht aufgefallen.
Ich bin nicht der Speicherplatz ausgegangen, und das passiert selbst dann, wenn ich genau einen Job zum erneuten Ausführen auswähle, sodass es nicht wie ein Race Condition aussieht. Es gibt hier eindeutig mehr als ein Problem, und was ich hier sehe, hat nichts mit dem verlinkten Thema zu tun.
(Es stellt sich heraus, dass ich doch kein Zertifikatproblem hatte; die Servernamen befanden sich im alternativen Servernamen. Aber ich bin trotzdem dazu übergegangen, den Hostnamen zu verwenden, der mit dem SN übereinstimmt, und es hat keinen Unterschied gemacht.)
Ich sende erfolgreich eine riesige Menge an E-Mails, nur diese wenigen Jobs stecken fest. Ich weiß zum Beispiel nicht, nach welchen Log-Einträgen ich suchen soll, um bei der Diagnose zu helfen.
Ich habe meine 29 fehlgeschlagenen E-Mails überprüft, um sicherzustellen, dass nichts Kritisch zu senden war, und soweit ich das beurteilen konnte, war nichts dabei, also habe ich alle Jobs in Sidekiq gelöscht, falls dies auf ein vorübergehendes Problem zurückzuführen war, das durch E-Mail-Jobs während Upgrades verursacht wurde. Ohne weitere Updates anzuwenden, habe ich nun jedoch einen weiteren Einzelfall desselben Fehlers.
Ich teile dies nur als Information mit, dass es sich um ein fortlaufendes Problem und nicht um ein seltsames vorübergehendes Problem handelt.
Der obige Codefix wurde übernommen. Können Sie die neuesten Änderungen per Git pull abrufen und Ihren Container neu erstellen, wenn Sie Gelegenheit dazu haben?
Das Upgrade und der erneute Versuch des Jobs haben das Senden der E-Mail erfolgreich abgeschlossen; ich habe die E-Mail-Protokolle überprüft und es wurde gemeldet, dass sie gesendet wurde.
