أواجه هذا الخطأ بشكل متكرر في Sidekiq (قوائم إعادة المحاولة والخطأ):
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
الوظائف التي لاحظت فيها هذا الخطأ المطابق هي:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
تم مناقشة هذا الأمر قليلاً في الماضي هنا: Feedback on the new Review Queue (2019) - #250 by markersocial
هل يمكنك تنفيذ الأمر التالي:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
شكرًا لك @Falco، لقد قمت بتشغيله الآن. إليك النتيجة:
-[ RECORD 1 ]--
id | 2147483496
حسنًا، إذن هذه هي مشكلة الحد الأقصى للأعداد الصحيحة الشهيرة. نحتاج إلى الانتقال إلى bigint لإصلاحها. سأقوم بالنظر في هذا.
للمرة الحالية، الحل البديل هو تشغيل:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
\q
exit
هذا هو الإعداد الافتراضي للتركيبات الجديدة، لكن التركيبات القديمة تحتوي على نوع بيانات خاطئ.
قد يكون تنفيذ الحل البديل صعبًا لأنه سيحجز الجدول، وقد تحتاج إلى تخفيف الحمل على الويب أولاً.
شكرًا لك يا @Falco ويا @sam - نقدر ذلك 
بخصوص الحل البديل، هل يُعتبر هذا آمنًا نسبيًا؟ لست قلقًا بشأن وقت التوقف، بل فقط من احتمال كسر شيء ما.
يستخدم حاوية واحدة قياسية من app.yml. لتخفيف الحمل على الويب، هل تعتقد أن استخدام وضع القراءة فقط وتشغيل ./launcher stop app ثم ./launcher start app قبل تنفيذ الحل البديل قد يكون كافيًا؟
لن يكسر أي شيء، وأسوأ سيناريو هو أن يعلق الأمر لفترة طويلة جدًا.
شكرًا لك سام، لقد قمت بحل المشكلة المؤقت. ومع ذلك، لم أحصل على أي رد عند إدخال الأمر التالي:
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
غير متأكد مما إذا كان لا يزال قيد المعالجة ربما. حاليًا، أواجه نفس الخطأ (في قائمة /sidekiq للأعمال الميتة، لأعمال المحاولة الأخيرة “قبل لحظة”) بالنسبة لـ:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
يبدو أنك بحاجة إلى التشغيل مع عمود post_id أيضًا
شكرًا لك!
للتأكد فقط، هل يبدو هذا صحيحًا؟
ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint
نعم، يجب أن يكون ذلك آمنًا. بمجرد إضافة عملية ترحيل رسمية، سيتم السماح بذلك.
ممتاز، شكرًا لك
لقد جربت ذلك (لم أحصل على تأكيد أو أي رد، مثل السابق). لم يتباطأ المنتدى، لذا لا أعرف ما إذا كان قد نجح. ما زلت أواجه نفس الأخطاء حاليًا.
ربما يكون من الأفضل أن أنتظر الهجرة الرسمية.
نعم، يبدو أن هذا موجود في جدول post_alerts، فنحن بحاجة إلى فحص العديد من الجداول.
هل أنت فضولي لمعرفة مكانك في هذه القضية الآن؟ هل توقفت الأخطاء؟
في الأصل، كنا نفكر في إجراء هجرة رسمية هنا، لكن المخاطر تفوق الفوائد بكثير. نجد أنه نادرًا ما نصادف قواعد بيانات تحتوي على أكثر من 2,147,483,647 منشورًا. 2.1 مليار رقم ضخم حقًا.
العيب في زيادة الحجم في كل مكان هو أن متطلبات التخزين ترتفع.
أما وضعنا الحالي فهو أننا ندرس إضافة مهمة rake “لإفساح المجال” في حال كنت في حالة شاذة حيث تحتوي جداولك في Discourse على ملياري صف (أو كان بها ملياري صف من التغييرات).
شكرًا لمتابعتك يا @sam
لقد قمت للتو بالترقية إلى الإصدار 2.8.0.beta6 ولا زلت أواجه أخطاء تجاوز نطاق الأرقام الصحيحة.
أعتقد أن المشكلة تكمن في الإشعارات التي وصلت إلى عدد هائل، وهو ما يبدو أكثر واقعية في الوصول إلى الحد الأقصى مقارنة بعدد المنشورات. فالكثير من المواضيع الكبيرة التي تحتوي على العديد من الردود والإعجابات وما إلى ذلك من مستخدمين مختلفين يمكن أن يؤدي إلى تراكم عدد كبير من الإشعارات.
يبدو أن مهمة Rake فكرة رائعة
أعلم أن هذا الموضوع قديم –
لقد واجهنا هذه المشكلة للتو في إعداداتنا أيضًا (devforum.roblox.com)! نحن نعمل بالإصدار v2.8.9، ولكن سيتم التحديث إلى 3.0.1 قريبًا.
لاحظنا وجود خطأ ما عندما بدأ المستخدمون في رؤية 403/500 أثناء محاولة الإعجاب/إلغاء الإعجاب بالمنشورات.
ثم عثرت على هذا الموضوع وتحققت من جدول الإشعارات الخاص بنا:
=> SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
id
------------
2147483647
(1 row)
@sam هل لا يزال الحل البديل المذكور أعلاه هو أفضل اقتراح، أم تم إعطاء المزيد من الاعتبار لمهمة rake منذ سبتمبر 2021؟
مزيد من المعلومات –
بعد تعديل عمود notifications.id، أرى مشكلة منفصلة من مهمة Jobs::PostAlert
Job exception: 2147498514 is out of range for ActiveModel::Type::Integer with limit 4 bytes
ربما هناك جدول/عمود آخر أفتقده؟ أو مكان ما في روبي لا يزال يتوقع نوع بيانات الأعداد الصحيحة؟
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'
نعم، هذه تظل الحل الوحيد هنا. أخشى تغييرها في النواة، لكن أعتقد أن هذا سيستمر في الحدوث في المنتديات الضخمة إذا لم نقم بإصلاح هذا.
العيب هو زيادة التخزين.
هل تعرف ما إذا كانت هناك أي استخدامات في خدمة post_actions (أو في مكان ما في عملية الإشعارات) قد لا تزال تتوقع أعدادًا صحيحة بعد تشغيل ALTER؟
نحن نرى أخطاء 5xx في استدعاءات الإعجاب/إلغاء الإعجاب لـ /post_actions مع الاستجابة:
{"errors":["The requested URL or resource could not be found."],"error_type":"not_found"}
بالإضافة إلى ذلك، فشلت بعض المهام المتعلقة بالإشعارات (Jobs::BookmarkReminderNotifications، Jobs::GrantAnniversaryBadges، Jobs::PostAlert).
لقد أضفت تتبع المكدس لـ PostAlert في رسالتي السابقة؛ يبدو أن هناك مشكلة يتم طرحها بسبب حد الأعداد الصحيحة بواسطة consolidate_or_create في notification.rb.
بالنسبة لاستخدامنا، فإن زيادة التخزين ليست مصدر قلق كبير إذا كان بإمكاننا استعادة الوظائف 
ربما حاول إعادة تشغيل الحاوية الخاصة بك، قد يكون هناك بعض الأشياء المخزنة مؤقتًا في الذاكرة.