Sto ricevendo spesso questo errore in Sidekiq (liste Riprova e Morti):
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
I job per cui ho notato questo identico errore sono:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Questo è stato discusso brevemente in passato qui: Feedback on the new Review Queue (2019) - #250 by markersocial
Puoi eseguire quanto segue:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
\q
exit
Grazie @Falco, l’ho appena eseguito. Ecco il risultato:
-[ RECORD 1 ]--
id | 2147483496
Ok, quindi è il famoso problema del massimo intero. Dobbiamo passare a bigint per risolverlo. Darò un’occhiata.
Per ora, la soluzione alternativa consiste nell’eseguire:
cd /var/discourse/
./launcher enter app
su postgres
psql
\x
\connect discourse
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
\q
exit
Questo è il valore predefinito per le nuove installazioni, ma le installazioni vecchie hanno il tipo di dati errato.
Eseguire la soluzione alternativa potrebbe essere difficile perché bloccherà la tabella; potresti dover prima ridurre il carico sul web.
Grazie @Falco e @sam - lo apprezziamo 
Per quanto riguarda la soluzione alternativa, dovrebbe essere relativamente sicuro farlo? Non mi preoccupa il tempo di inattività, ma solo il rischio di rompere qualcosa.
Stiamo usando il singolo contenitore standard app.yml. Per alleggerire il carico sul web, pensi che usare la modalità sola lettura ed eseguire ./launcher stop app, ./launcher start app prima di applicare la soluzione alternativa sia sufficiente?
Non romperà nulla; nel peggiore dei casi, rimarrà semplicemente “bloccato” per molto tempo.
Grazie Sam, ho applicato la soluzione alternativa. Tuttavia, non ho ricevuto alcun feedback dopo aver inserito:
ALTER TABLE notifications ALTER COLUMN id SET DATA TYPE bigint
Non sono sicuro che sia ancora in elaborazione. Attualmente ricevo lo stesso errore (nell’elenco /sidekiq dead, per gli ultimi tentativi di ‘appena ora’) per:
Jobs::PostAlert
Jobs::ProcessPost
Jobs::NotifyCategoryChange
Sembra che tu debba eseguire l’operazione includendo anche la colonna post_id
Grazie!
Per sicurezza, questo sembra corretto?
ALTER TABLE notifications ALTER COLUMN post_id SET DATA TYPE bigint
Sì, dovrebbe essere sicuro: una volta aggiunta una migrazione ufficiale, questa lo consentirà.
Perfetto, grazie
L’ho eseguito (nessuna conferma o riscontro ricevuto, come nel caso precedente). Il forum non ha rallentato, quindi non sono sicuro che abbia funzionato. Sto ricevendo gli stessi errori al momento.
Forse sarebbe meglio se aspettassi la migrazione ufficiale.
Sì, sembra che questo sia nella tabella post_alerts, dobbiamo scorrere molte tabelle
Sei curioso di sapere dove ti trovi ora su questo problema? Gli errori sono cessati?
Inizialmente avevamo pensato di effettuare una migrazione ufficiale, ma il rischio supera di gran lunga il beneficio. È estremamente raro imbattersi in database con più di 2.147.483.647 post. 2,1 miliardi è un numero davvero enorme.
Lo svantaggio dell’aumento delle dimensioni ovunque è che aumentano i requisiti di archiviazione.
La situazione attuale è che stiamo valutando di aggiungere un task rake che “libera spazio” nel caso raro in cui si abbiano tabelle in Discourse contenenti 2 miliardi di righe (o che ne abbiano contenute 2 miliardi in passato).
Grazie per il follow-up @sam
Ho appena aggiornato alla versione 2.8.0.beta6 e continuo a ricevere errori di “integer out of range”.
Penso che il problema sia legato alle notifiche, che hanno raggiunto un numero enorme, il che rende più realistico il raggiungimento del limite rispetto al numero di post. Molti argomenti grandi con numerose risposte, like, ecc., provenienti da diversi utenti, possono generare un gran numero di notifiche.
Un task rake sembra fantastico
So che questo è un thread vecchio –
Abbiamo appena riscontrato questo problema anche nella nostra configurazione (devforum.roblox.com)! Stiamo eseguendo la v2.8.9, ma aggiorneremo presto alla 3.0.1.
Abbiamo notato che qualcosa non andava quando gli utenti hanno iniziato a vedere 403/500 mentre cercavano di mettere “mi piace” o togliere “mi piace” ai post.
Poi mi sono imbattuto in questo thread e ho controllato la nostra tabella delle notifiche:
=> SELECT id FROM notifications ORDER BY 1 DESC LIMIT 1;
id
------------
2147483647
(1 row)
@sam La soluzione alternativa sopra è ancora il miglior suggerimento, o è stata data maggiore considerazione a un rake task da settembre 2021?
Maggiori informazioni –
Dopo aver modificato la colonna notifications.id, sto riscontrando un problema separato dal job Jobs::PostAlert
Job exception: 2147498514 è fuori intervallo per ActiveModel::Type::Integer con limite di 4 byte
Forse c’è un’altra tabella/colonna che mi manca? O da qualche parte in ruby che si aspetta ancora il tipo di dati integer?
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'
Sì, questo rimane l’unico workaround qui. Sono preoccupato di cambiarlo nel core, ma immagino che questo continuerà a succedere su forum giganteschi se non lo risolveremo.
Lo svantaggio è l’aumento dello spazio di archiviazione.
Sai se ci sono utilizzi nel servizio post_actions (o da qualche parte nel processo di notifica) che potrebbero ancora aspettarsi interi dopo aver eseguito ALTER?
Stiamo riscontrando errori 5xx nelle chiamate like/unlike a /post_actions con la risposta
{"errors":["The requested URL or resource could not be found."],"error_type":"not_found"}
Inoltre, alcuni job falliscono intorno alle notifiche (Jobs::BookmarkReminderNotifications, Jobs::GrantAnniversaryBadges, Jobs::PostAlert).
Ho aggiunto il backtrace per PostAlert nel mio messaggio precedente; sembra che ci sia un problema lanciato per un limite intero da consolidate_or_create in notification.rb.
Per il nostro utilizzo, l’aumento dello spazio di archiviazione non è una grossa preoccupazione se possiamo ripristinare la funzionalità 
Prova a riavviare il tuo container, potrebbe esserci della cache in memoria.