Ich bekomme diesen Fehler in Sidekiq (Retries- und Dead-Listen) häufig:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
Bei folgenden Jobs ist mir dieser identische Fehler aufgefallen:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Dies wurde bereits hier etwas diskutiert: Feedback on the new Review Queue (2019) - #250 by markersocial
Kannst du bitte Folgendes ausführen:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
Danke @Falco, ich habe es gerade ausgeführt. Hier ist das Ergebnis:
-[ RECORD 1 ]--
id | 2147483496
Okay, also das ist das berühmte Integer-Max-Problem. Wir müssen auf bigint umsteigen, um das zu beheben. Ich werde mir das ansehen.
Vorübergehend ist Ihre Workaround-Lösung, folgenden Befehl auszuführen:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
\q
exit
Dies ist der Standard für neue Installationen, aber bei älteren Installationen ist der falsche Datentyp verwendet worden.
Die Ausführung der Workaround-Lösung kann schwierig sein, da sie die Tabelle blockiert. Möglicherweise müssen Sie zunächst die Weblast reduzieren.
Danke @Falco & @sam – das wird geschätzt 
Bezüglich der Workaround-Lösung: Ist das relativ sicher durchzuführen? Ich mache mir keine Sorgen um Ausfallzeiten, sondern nur darum, etwas kaputtzumachen.
Es wird die Standard app.yml mit einem einzelnen Container verwendet. Um die Weblast abzubauen, denkst du, dass der Einsatz des Nur-Lese-Modus und das Ausführen von ./launcher stop app, ./launcher start app vor der Workaround-Lösung wahrscheinlich ausreichen?
Es wird nichts kaputtgehen. Im schlimmsten Fall bleibt es nur sehr lange „stecken".
Danke, Sam, ich habe den Workaround angewendet. Allerdings habe ich nach der Eingabe keine Rückmeldung erhalten:
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
Ich bin mir nicht sicher, ob es vielleicht noch verarbeitet wird. Derzeit erhalte ich denselben Fehler (in der /sidekiq dead-Liste für Jobs mit dem letzten Versuch „gerade eben") für:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Sieht so aus, als müsstest du auch mit der post_id-Spalte einsteigen.
Danke!
Nur zur Sicherheit, sieht das korrekt aus?
ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint
Ja, das sollte sicher sein. Sobald wir eine offizielle Migration hinzufügen, wird dies unterstützt.
Perfekt, danke
Ich habe das ausgeführt (keine Bestätigung/Rückmeldung erhalten, wie beim vorherigen). Das Forum wurde nicht langsamer, also bin ich mir nicht sicher, ob es funktioniert hat. Ich bekomme derzeit dieselben Fehler.
Vielleicht wäre es am besten, wenn ich auf die offizielle Migration warte.
Ja, sieht so aus, als ob das in der Tabelle post_alerts steht. Wir müssen viele Tabellen durchsuchen.
Neugierig, wie es bei Ihnen mit diesem Thema aktuell aussieht? Sind die Fehler verschwunden?
Ursprünglich planten wir eine offizielle Migration, doch das Risiko überwiegt den Nutzen bei Weitem. Es ist außerordentlich selten, Datenbanken mit mehr als 2.147.483.647 Beiträgen zu finden. 2,1 Milliarden ist eine wirklich große Zahl.
Der Nachteil einer Vergrößerung an allen Stellen besteht darin, dass die Speicheranforderungen steigen.
Unser aktueller Stand ist, dass wir prüfen, einen rake-Task hinzuzufügen, der „Platz schafft", falls Sie einen Ausnahmefall haben, bei dem Tabellen in Discourse 2 Milliarden Zeilen enthalten (oder 2 Milliarden Zeilen an Änderungen durchlaufen haben).
Danke für die Rückmeldung, @sam.
Ich habe gerade auf 2.8.0.beta6 aktualisiert und erhalte immer noch Fehler wegen eines Wertebereichs-Überschreitens bei ganzen Zahlen.
Ich vermute, dass es einfach die Benachrichtigungen sind, die eine riesige Anzahl erreicht haben. Das ist realistischer, die Grenze zu erreichen, als bei der Anzahl der Beiträge. Viele große Themen mit zahlreichen Antworten, Likes usw. von verschiedenen Benutzern können zu einer erheblichen Menge an Benachrichtigungen führen.
Ein Rake-Task klingt fantastisch
Ich weiß, dass dies ein alter Thread ist –
Wir sind gerade auf dasselbe Problem in unserem Setup gestoßen (devforum.roblox.com)! Wir verwenden v2.8.9, werden aber bald auf 3.0.1 aktualisieren.
Wir bemerkten, dass etwas nicht stimmte, als Benutzer beim Liken/Entliken von Beiträgen entweder 403/500 sahen.
Dann stieß ich auf diesen Thread und überprüfte unsere Benachrichtigungstabelle:
=> SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
id
------------
2147483647
(1 row)
@sam Ist der obige Workaround immer noch der beste Vorschlag, oder wurde seit September 2021 mehr über eine Rake-Aufgabe nachgedacht?
Weitere Informationen –
Nachdem ich die Spalte notifications.id geändert habe, sehe ich ein weiteres Problem mit dem Job Jobs::PostAlert
Job exception: 2147498514 ist außerhalb des Bereichs für ActiveModel::Type::Integer mit Limit von 4 Bytes
Vielleicht fehlt mir eine andere Tabelle/Spalte? Oder irgendwo in Ruby, das immer noch den Integer-Datentyp erwartet?
activemodel-6.1.6.1/lib/active_model/type/integer.rb:49:in `ensure_in_range'
activemodel-6.1.6.1/lib/active_model/type/integer.rb:28:in `serialize'
activemodel-6.1.6.1/lib/active_model/attribute.rb:56:in `value_for_database'
activemodel-6.1.6.1/lib/active_model/attribute.rb:68:in `forgetting_assignment'
activemodel-6.1.6.1/lib/active_model/attribute_set.rb:90:in `transform_values'
activemodel-6.1.6.1/lib/active_model/attribute_set.rb:90:in `map'
activemodel-6.1.6.1/lib/active_model/dirty.rb:262:in `forget_attribute_assignments'
activemodel-6.1.6.1/lib/active_model/dirty.rb:154:in `changes_applied'
activerecord-6.1.6.1/lib/active_record/attribute_methods/dirty.rb:202:in `_create_record'
activerecord-6.1.6.1/lib/active_record/callbacks.rb:461:in `block in _create_record'
activesupport-6.1.6.1/lib/active_support/callbacks.rb:106:in `run_callbacks'
activesupport-6.1.6.1/lib/active_support/callbacks.rb:824:in `_run_create_callbacks'
activerecord-6.1.6.1/lib/active_record/callbacks.rb:461:in `_create_record'
activerecord-6.1.6.1/lib/active_record/timestamp.rb:108:in `_create_record'
activerecord-6.1.6.1/lib/active_record/persistence.rb:900:in `create_or_update'
activerecord-6.1.6.1/lib/active_record/callbacks.rb:457:in `block in create_or_update'
activesupport-6.1.6.1/lib/active_support/callbacks.rb:106:in `run_callbacks'
activesupport-6.1.6.1/lib/active_support/callbacks.rb:824:in `_run_save_callbacks'
activerecord-6.1.6.1/lib/active_record/callbacks.rb:457:in `create_or_update'
activerecord-6.1.6.1/lib/active_record/timestamp.rb:126:in `create_or_update'
activerecord-6.1.6.1/lib/active_record/persistence.rb:507:in `save!'
activerecord-6.1.6.1/lib/active_record/validations.rb:53:in `save!'
activerecord-6.1.6.1/lib/active_record/transactions.rb:302:in `block in save!'
activerecord-6.1.6.1/lib/active_record/transactions.rb:354:in `block in with_transaction_returning_status'
activerecord-6.1.6.1/lib/active_record/connection_adapters/abstract/database_statements.rb:320:in `block in transaction'
activerecord-6.1.6.1/lib/active_record/connection_adapters/abstract/transaction.rb:319:in `block in within_new_transaction'
activesupport-6.1.6.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:26:in `block (2 levels) in synchronize'
activesupport-6.1.6.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `handle_interrupt'
activesupport-6.1.6.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:25:in `block in synchronize'
activesupport-6.1.6.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `handle_interrupt'
activesupport-6.1.6.1/lib/active_support/concurrency/load_interlock_aware_monitor.rb:21:in `synchronize'
activerecord-6.1.6.1/lib/active_record/connection_adapters/abstract/transaction.rb:317:in `within_new_transaction'
activerecord-6.1.6.1/lib/active_record/connection_adapters/abstract/database_statements.rb:320:in `transaction'
activerecord-6.1.6.1/lib/active_record/transactions.rb:350:in `with_transaction_returning_status'
activerecord-6.1.6.1/lib/active_record/transactions.rb:302:in `save!'
activerecord-6.1.6.1/lib/active_record/suppressor.rb:48:in `save!'
/app/app/models/notification.rb:40:in `tap'
/app/app/models/notification.rb:40:in `consolidate_or_create!'
activerecord-6.1.6.1/lib/active_record/relation/delegation.rb:67:in `block in consolidate_or_create!'
activerecord-6.1.6.1/lib/active_record/relation.rb:406:in `block in scoping'
activerecord-6.1.6.1/lib/active_record/relation.rb:804:in `_scoping'
activerecord-6.1.6.1/lib/active_record/relation.rb:406:in `scoping'
activerecord-6.1.6.1/lib/active_record/associations/collection_proxy.rb:1109:in `scoping'
activerecord-6.1.6.1/lib/active_record/relation/delegation.rb:67:in `consolidate_or_create!'
/app/app/services/post_alerter.rb:496:in `create_notification'
/app/app/services/post_alerter.rb:825:in `block in notify_post_users'
/app/app/services/post_alerter.rb:838:in `block (2 levels) in each_user_in_batches'
activerecord-6.1.6.1/lib/active_record/relation/delegation.rb:88:in `each'
activerecord-6.1.6.1/lib/active_record/relation/delegation.rb:88:in `each'
/app/app/services/post_alerter.rb:838:in `block in each_user_in_batches'
/app/app/services/post_alerter.rb:837:in `each'
/app/app/services/post_alerter.rb:837:in `each_slice'
/app/app/services/post_alerter.rb:837:in `each_user_in_batches'
/app/app/services/post_alerter.rb:821:in `notify_post_users'
/app/app/services/post_alerter.rb:162:in `after_save_post'
/app/app/jobs/regular/post_alert.rb:11:in `execute'
/app/app/jobs/base.rb:232:in `block (2 levels) in perform'
/app/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/app/app/jobs/base.rb:221:in `block in perform'
/app/app/jobs/base.rb:217:in `each'
/app/app/jobs/base.rb:217:in `perform'
sidekiq-6.3.1/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.3.1/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/app/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.3.1/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.3.1/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.3.1/lib/sidekiq/job_retry.rb:112:in `local'
sidekiq-6.3.1/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.3.1/lib/sidekiq/rails.rb:14:in `block in call'
activesupport-6.1.6.1/lib/active_support/execution_wrapper.rb:91:in `wrap'
activesupport-6.1.6.1/lib/active_support/reloader.rb:72:in `block in wrap'
activesupport-6.1.6.1/lib/active_support/execution_wrapper.rb:91:in `wrap'
activesupport-6.1.6.1/lib/active_support/reloader.rb:71:in `wrap'
sidekiq-6.3.1/lib/sidekiq/rails.rb:13:in `call'
sidekiq-6.3.1/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.3.1/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.3.1/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.3.1/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.3.1/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.3.1/lib/sidekiq/job_retry.rb:79:in `global'
sidekiq-6.3.1/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.3.1/lib/sidekiq/logger.rb:11:in `with'
sidekiq-6.3.1/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.3.1/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.3.1/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.3.1/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.3.1/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.3.1/lib/sidekiq/util.rb:43:in `watchdog'
sidekiq-6.3.1/lib/sidekiq/util.rb:52:in `block in safe_thread'
Ja, das bleibt hier die einzige Lösung. Ich mache mir Sorgen, es im Kern zu ändern, aber ich schätze, das wird bei riesigen Foren immer wieder passieren, wenn wir das nicht beheben.
Der Nachteil ist der erhöhte Speicherplatz.
Wissen Sie, ob es im post_actions-Dienst (oder irgendwo im Benachrichtigungsprozess) Verwendungen gibt, die nach der Ausführung von ALTER immer noch Integer erwarten?
Wir sehen 5xx-Fehler bei Like/Unlike-Aufrufen an /post_actions mit der Antwort
{"errors":["Die angeforderte URL oder Ressource konnte nicht gefunden werden."],"error_type":"not_found"}
Außerdem gab es einige fehlgeschlagene Jobs rund um Benachrichtigungen (Jobs::BookmarkReminderNotifications, Jobs::GrantAnniversaryBadges, Jobs::PostAlert).
Ich habe den Backtrace für PostAlert in meiner vorherigen Nachricht hinzugefügt; es sieht so aus, als gäbe es ein Problem mit einem Integer-Limit, das von consolidate_or_create in notification.rb ausgelöst wird.
Für unsere Nutzung ist eine erhöhte Speicherung kein großes Problem, wenn wir die Funktionalität wiederherstellen können 
Versuchen Sie vielleicht, Ihren Container neu zu starten. Möglicherweise befinden sich einige gecachte Elemente im Speicher.