Sì, quando un utente viene eliminato, lo rimuoviamo da tutti gli eventi a cui ha risposto. Forse è quel codice a causare questo problema.
3 Mi Piace
Perché tutti gli ID dei topic nell’errore sono topic che utilizzano Events.
Hmm, sono abbastanza sicuro che questi specifici utenti che sto eliminando non abbiano risposto, ma potrebbe essere che questi siano gli unici topic con la risposta abilitata?
3 Mi Piace
Oh, ok, ho capito.
@fzngagan qui si sta usando un .find( non sicuro?
topics = Topic.find(topic_ids) if topic_ids
Vedi la correzione che ho appena inviato a Follow (anche se la soluzione qui potrebbe dover essere diversa dato che ci sono più ID: usare where?)
3 Mi Piace
Ho appena aggiornato, ma ricevo ancora l’errore 404.
1 Mi Piace
Bart, aspetta che @fzngagan applichi e confermi una correzione.
5 Mi Piace
Ho applicato una correzione. Dovrebbe risolvere il problema. Per favore, controlla e conferma.
5 Mi Piace
Ha risolto, grazie!!
6 Mi Piace
Ho visto più volte post nella coda di revisione con il motivo “Nuovo utente ha scritto il primo post sospettosamente in fretta”.
Dopo un’ulteriore verifica, ho notato che tali post contenevano una parola monitorata, ma questo non veniva menzionato nella coda di revisione.
Poiché il flag “Nuovo utente ha scritto il primo post sospettosamente in fretta” è errato nel 96% dei casi, mentre i flag per “parole monitorate” sono corretti al 100%, ovvero se un post finisce nella coda di revisione a causa di una parola monitorata, è certo al 100% che richieda davvero attenzione, ritengo che le “parole monitorate” dovrebbero avere la precedenza rispetto a “nuovo utente ha scritto troppo in fretta”.
Immagina le seguenti situazioni:
- Un post entra nella coda di revisione a causa di “Nuovo utente ha scritto il primo post sospettosamente in fretta”. Questo post contiene un link spam invisibile presente nell’elenco delle “parole monitorate”. → Il post viene approvato, poiché nessuno nota il link invisibile (ad esempio, un link nascosto dietro un “.”). → Fallimento!
- Un post entra nella coda di revisione a causa di una parola monitorata (le “parole monitorate” hanno la precedenza su “scritto troppo in fretta”). Questo post contiene un link spam invisibile presente nell’elenco delle “parole monitorate”. → Il post viene rifiutato e lo spammer viene eliminato a causa delle “parole monitorate” → Vittoria!
5 Mi Piace
Assolutamente, questo è un bug al limite della definizione; potremmo aggiungerlo alla lista di qualcuno @eviltrout? Vedo che @Roman è ancora assegnato, forse?
4 Mi Piace
Corretto qui:
8 Mi Piace
Su 2.6.0.beta2. Solo un avviso: ho in coda argomenti che sembrano essere stati eliminati. Quindi penso che il meccanismo sia qualcosa del genere:
- Il messaggio di un utente viene inserito nella coda di revisione a causa della velocità di digitazione.
- L’utente elimina il proprio argomento (se possibile), forse per ripubblicarlo.
Non sono sicuro che questo sia il comportamento previsto. Nella coda di revisione il titolo è vuoto, ma il corpo del messaggio è presente e l’utente è silenziato. Non riesco a vedere alcun argomento/messaggio nel profilo pubblico dell’utente.
Non correlato a quanto sopra. Ho un suggerimento per le opzioni di filtraggio. Una funzione che sarebbe piuttosto ottima, a mio avviso, sarebbe un filtro più granulare per i tipi di messaggio/argomento. Attualmente per i Tipi abbiamo:
Messaggio segnalato e Messaggio in coda includono sia Argomenti che Messaggi. Penso che sarebbe molto utile se questo venisse modificato in:
Tipo di revisione:
- Segnalato
- In coda
Si potrebbe anche valutare di dividere ‘Segnalato’ in ‘Segnalato dall’utente’ e ‘Segnalato dal sistema’.
Poi aggiungere un altro filtro per il tipo di contenuto.
Tipo di contenuto:
- Argomento
- Messaggio
- Utente
Penso che questo sarebbe molto utile. Ad esempio, si potrebbe dare priorità in modo rapido all’approvazione degli argomenti rispetto a quella dei messaggi/risposte. Con i filtri attuali, non c’è un vero modo per differenziare tra Argomenti e Messaggi, a parte ‘Raggruppati per Argomento’.
Un altro suggerimento sarebbe modificare l’interfaccia della coda di revisione in modo che Argomenti e Messaggi siano un po’ più facili da distinguere. Attualmente queste informazioni sono mostrate come un piccolo testo grigio (cioè Messaggio in coda, Argomento in coda, Messaggio segnalato, Argomento segnalato). La dimensione del testo è la stessa delle categorie e dei tag dell’argomento/messaggio.
Per me, non è immediatamente ovvio se l’elemento sia un argomento o un messaggio/risposta, e spesso confondo i due.
Alcune idee:
- Modificare la sezione Titolo dell’argomento negli elementi dei messaggi per includere un’icona di risposta, renderla più piccola rispetto agli elementi argomento e forse aggiungere il testo RE:
- Aumentare la dimensione del testo/enfasi sul tipo di elemento (Argomento/Messaggio).
2 Mi Piace
Quando provo ad approvare argomenti e post, ricevo un errore 500. Attualmente sto utilizzando la versione 2.6.0.beta3. Ecco il log:
ActiveRecord::RangeError (PG::NumericValueOutOfRange: ERROR: integer out of range
)
app/models/reviewable_queued_post.rb:97:in `perform_approve_post'
app/models/reviewable.rb:355:in `public_send'
app/models/reviewable.rb:355:in `block in perform'
app/models/reviewable.rb:353:in `perform'
app/controllers/reviewables_controller.rb:192:in `perform'
app/controllers/application_controller.rb:347:in `block in with_resolved_locale'
app/controllers/application_controller.rb:347:in `with_resolved_locale'
lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
lib/content_security_policy/middleware.rb:12:in `call'
lib/middleware/anonymous_cache.rb:336:in `call'
config/initializers/100-quiet_logger.rb:23:in `call'
config/initializers/100-silence_logger.rb:31:in `call'
lib/middleware/enforce_hostname.rb:22:in `call'
lib/middleware/request_tracker.rb:176:in `call'
Alcune informazioni potenzialmente rilevanti sono che in passato avevo installato Akismet e l’ho rimosso (ho eseguito anche il task rake), come dettagliato qui: Feedback on the new Review Queue (2019) - #210 by markersocial
Gli elementi sono relativi agli ultimi 60 giorni (auto_handle_queued_age: 60). Ho provato sia con post vecchi (~2 mesi) che recenti (negli ultimi 3 ore).
Posso approvare gli utenti (Tipo: Utente) e l’opzione ‘Elimina Utente’ sugli argomenti/post in coda funziona.
2 Mi Piace
@Roman questo è super strano - come mai abbiamo qui un numero intero enorme?
6 Mi Piace
L’errore viene generato quando si tenta di creare una notifica:
Sospetto che stiamo probabilmente memorizzando
Forse stiamo memorizzando alcuni ID utilizzando il tipo int? Rails ha iniziato a utilizzare BIGINT(8) per le chiavi primarie dalla versione 5.1.
@markersorcial Potresti condividere con noi i risultati di queste query?
Notification.count
User.count
Topic.count
4 Mi Piace
Grazie per averci dato un’occhiata 
Certo, ecco i risultati della query:
Notification.count: 1506604
User.count: 238083
Topic.count: 936067
3 Mi Piace
Aggiornamento: Guardando in Sidekiq, vedo molti task falliti con questo errore che sembra simile:
Jobs::HandledExceptionWrapper: Wrapped ActiveRecord::RangeError: PG::NumericValueOutOfRange: ERROR: integer out of range
Per questi tipi di Task (che ho notato finora):
Jobs::PostAlert (il più comune)
Jobs::ProcessPost
Jobs::NotifyCategoryChange
1 Mi Piace
Nessuno di quei numeri dovrebbe superare la dimensione massima. Mi chiedo se qualcos’altro stia sovrascrivendo un valore intero @Roman.
3 Mi Piace
Deve essere qualcos’altro allora. C’è sicuramente qualcosa che non va e non è specifico della coda di revisione.
Questi job creano notifiche e stanno fallendo anch’essi:
Inoltre, se provo a fare qualcosa del genere:
Notification.create!(
notification_type: Notification.types[:post_approved],
user_id: 1,
data: {},
topic_id: 1,
post_number: 1311344111111
)
ottengo un errore diverso:
ActiveModel::RangeError: 1311344111111 è fuori range per ActiveModel::Type::Integer con limite di 4 byte
Ho ottenuto lo stesso errore facendo questo:
DB.exec <<~SQL
INSERT INTO notifications(user_id, topic_id, post_number)
VALUES (1, 1, 1311344111111)
SQL
PG::NumericValueOutOfRange: ERRORE: integer fuori range
6 Mi Piace
@markersocial Mi chiedo se i log di PostgreSQL possano fornirci maggiori informazioni sull’errore. Potresti controllare?
Se non sai dove trovare i log, consulta:
5 Mi Piace
I nostri moderatori apprezzano la possibilità di discutere facilmente tra loro i Post Segnalati e di mantenere lo storico nella Coda di Revisione. Sarebbe possibile aggiungere la stessa funzionalità ai Post in Coda? Utilizziamo l’impostazione approve_post_count per richiedere l’approvazione per i primi 5 post di un nuovo utente. Quei primi 5 post diventano Post in Coda, ma se è necessaria una discussione tra i moderatori, devono avviare un messaggio privato che è scollegato dalla Coda di Revisione e lo storico viene perso.
3 Mi Piace