Getting this error a lot in Sidekiq (Retries and Dead lists):
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
The jobs I’ve noticed this identical error for are:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
This was discussed a bit in the past here: Feedback on the new Review Queue - #250 by markersocial
Can you please run:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
Thanks @Falco, I just ran it now. Here is the result:
-[ RECORD 1 ]--
id | 2147483496
Okay, so it’s the famous integer max problem. We need to move to bigint to fix this. I will take a look into this.
For now your workaround is to run:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
\q
exit
This is the default for new installs but old installs have the wrong data type.
Running the workaround may be hard cause it will block the table, you many need to shed your web load first.
Thanks @Falco & @sam - appreciate it 
Regarding the workaround, this should be relatively safe to do? Not worried about down time, just breaking something.
It’s using the standard app.yml single container. For shedding the web load, do you think using read-only mode and running ./launcher stop app, ./launcher start app prior to doing the workaround probably suffice?
It will not break anything, worst case is that it will just be “stuck” for a very long time.
Thanks Sam, I did the workaround. Though, did not get any feedback upon inputting:
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
Not sure if it’s still processing perhaps. Currently getting the same error (in the /sidekiq dead list, for last retry ‘just now’ jobs) for:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Looks like you need to run in with post_id column as well
Thanks!
Just to be sure, does this look correct?
ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint
Yes that should be safe, once we add an official migration it will allow for it
Perfect, thanks
I ran that (no confirmation/feedback received, like the previous one). Forum didn’t slow down, so not sure if it worked. Getting the same errors currently.
Maybe it would be best if I wait for the official migration.
Yeah looks like this is in the post_alerts table, we need to sweep through many tables
Curious where you are on this issue now? Did the errors stop?
Originally we were thinking of making some official migration here, but the risk far outweighs the benefit. We find it exceedingly rare to come across DBs with more than 2,147,483,647 posts. 2.1 billion is a real big number.
The downside of increasing the sized everywhere are that storage requirements go up.
Where we are now is that we are considering adding a rake task that “makes space” if you are in an outlier case where you have tables in Discourse that containe 2 billion rows (or had 2 billion rows of churn)
Thanks for the follow up @sam
I just upgraded to 2.8.0.beta6 and still getting the integer out of range errors.
I think that it’s just the notifications that has got to a massive number, which is a bit more realistic to reach the limit compared to number of posts. A lot of large topics with many replies, likes etc. from different users can result in quite a lot of notifications.
A rake task sounds fantastic
我知道这是一个旧的帖子——
我们也在我们的设置（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 上面的解决方法仍然是最好的建议吗，还是自 2021 年 9 月以来对 rake 任务给予了更多考虑？
更多信息 –
在修改了 notifications.id 列后，我遇到了一个与 Jobs::PostAlert 作业分开的问题。
Job exception: 2147498514 超出范围 ActiveModel::Type::Integer 的 4 字节限制
也许我遗漏了另一个表/列？或者 Ruby 中有地方仍然期望整数数据类型？
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 后仍期望整数的用法？
我们看到对 /post_actions 的点赞/取消点赞调用出现 5xx 错误，响应为：
{"errors":["找不到请求的 URL 或资源。"],"error_type":"not_found"}
此外，还有一些与通知相关的作业失败（Jobs::BookmarkReminderNotifications、Jobs::GrantAnniversaryBadges、Jobs::PostAlert）。
我在上一条消息中添加了 PostAlert 的回溯信息；看起来 notification.rb 中的 consolidate_or_create 在 notification.rb 中抛出了一个关于整数限制的问题。
对我们来说，如果能恢复功能，增加存储空间并不是太大的问题 
也许可以尝试重启容器，可能是内存中有缓存的东西。