# Error: integer out of range
**URL:** https://meta.discourse.org/t/error-integer-out-of-range/200619
**Category:** Bug
**Created:** [August 16, 2021, 4:35pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619 "2021-08-16T16:35:24Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 16, 2021, 4:35pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/1 "2021-08-16T16:35:24Z")
Getting this error a lot in Sidekiq (Retries and Dead lists):
```plaintext
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 (2019) - #250 by markersocial](https://meta.discourse.org/t/feedback-on-the-new-review-queue/112837/250)
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 16, 2021, 5:20pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/2 "2021-08-16T17:20:31Z")
Can you please run:
```plaintext
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
```
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 16, 2021, 5:25pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/3 "2021-08-16T17:25:31Z")
Thanks @Falco, I just ran it now. Here is the result:
```plaintext
-[RECORD 1]--
id | 2147483496
```
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [August 16, 2021, 5:33pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/4 "2021-08-16T17:33:16Z")
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 17, 2021, 12:50am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/5 "2021-08-17T00:50:44Z")
For now your workaround is to run:
```plaintext
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.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 17, 2021, 6:48am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/6 "2021-08-17T06:48:16Z")
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?
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 17, 2021, 6:54am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/7 "2021-08-17T06:54:06Z")
> [@markersocial](#):
>
> Not worried about down time, just breaking something.
It will not break anything, worst case is that it will just be “stuck” for a very long time.
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 17, 2021, 8:14am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/8 "2021-08-17T08:14:11Z")
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
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 17, 2021, 8:29am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/9 "2021-08-17T08:29:50Z")
Looks like you need to run in with post\_id column as well
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 17, 2021, 8:40am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/10 "2021-08-17T08:40:48Z")
Thanks! 🙂
Just to be sure, does this look correct?
`ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint`
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 17, 2021, 8:43am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/11 "2021-08-17T08:43:11Z")
Yes that should be safe, once we add an official migration it will allow for it
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [August 17, 2021, 9:09am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/12 "2021-08-17T09:09:24Z")
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.
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [August 17, 2021, 9:57am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/13 "2021-08-17T09:57:43Z")
Yeah looks like this is in the post\_alerts table, we need to sweep through many tables
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [September 7, 2021, 5:32am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/15 "2021-09-07T05:32:40Z")
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)
---
### Author:  [@markersocial](https://meta.discourse.org/u/markersocial)
#### Post date: [September 7, 2021, 9:56am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/16 "2021-09-07T09:56:40Z")
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 🙂
---
### Author:  [@bjlarouche](https://meta.discourse.org/u/bjlarouche)
#### Post date: [February 14, 2023, 10:11pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/17 "2023-02-14T22:11:20Z")
I know this is an old thread –
We just hit this issue on our setup as well ([devforum.roblox.com](http://devforum.roblox.com))! We’re running v2.8.9, but will be updating to 3.0.1 soon.
We noticed something was wrong when users started seeing either 403/500 while trying to like/unlike posts.
Then I stumbled across this thread and checked our notifications table:
```plaintext
=> SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
id
------------
2147483647
(1 row)
```
@sam Is the above workaround still the best suggestion, or was more consideration given to a rake task since Sep 2021?
---
### Author:  [@bjlarouche](https://meta.discourse.org/u/bjlarouche)
#### Post date: [February 14, 2023, 11:34pm UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/18 "2023-02-14T23:34:58Z")
More info –
After altering the notifications.id column, I’m seeing a separate issue from the ` Jobs::PostAlert` job
`Job exception: 2147498514 is out of range for ActiveModel::Type::Integer with limit 4 bytes`
Maybe there’s another table/column I’m missing? Or somewhere in ruby that’s still expecting the integer data type?
> **backtrace**
>
> ```plaintext
> 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'
>
> rails_multisite-4.0.0/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'
>
> ```
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [February 15, 2023, 1:25am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/19 "2023-02-15T01:25:27Z")
> [@markersocial](#):
>
> ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
Yes this remains the only workaround here. I worry about changing it in core, but I guess this is just going to keep happening on gigantic forums if we don’t fix this.
The downside is increased storage.
---
### Author:  [@bjlarouche](https://meta.discourse.org/u/bjlarouche)
#### Post date: [February 15, 2023, 1:35am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/20 "2023-02-15T01:35:37Z")
Do you know if there are any usages in the post\_actions service (or somewhere in the notification process) that might still be expecting integers after runing ALTER?
We’re seeing 5xx errors on like/unlike calls to `/post_actions` with the response
```sh
{"errors":["The requested URL or resource could not be found."],"error_type":"not_found"}
```
Plus, some the job failures around notfications (Jobs::BookmarkReminderNotifications, Jobs::GrantAnniversaryBadges, Jobs::PostAlert).
I added the backtrace for PostAlert in my prev message; looks like theres an issue being thrown for an integer limit by `consolidate_or_create` in [notification.rb](https://github.com/discourse/discourse/blob/1503ec07c57898a507395552b765b6808b4e1db9/app/models/notification.rb#L34).
For our usage, increased storage isn’t too big of a concern if we can restore functionality 🤞
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [February 15, 2023, 1:46am UTC](https://meta.discourse.org/t/error-integer-out-of-range/200619/21 "2023-02-15T01:46:46Z")
Maybe try restarting your container, could be some cached stuff in memory.
[Next page](https://meta.discourse.org/t/error-integer-out-of-range/200619.md?page=2)