Abbiamo un webhook sull’evento “user_logged_in”. Il Payload contiene la proprietà post_count per l’utente che ha appena effettuato l’accesso. Sebbene l’utente abbia scritto 2 post, il payload indica post_count: 0. Questo mi sembra un bug.
Il ricevitore del webhook necessita di questa statistica utente per decidere come procedere.
Devo correggermi: il post_count non è sempre zero. Controllando con il mio utente, il post_count era plausibile (anche se non so se sia accurato o meno).
Ma c’è un utente sul nostro sito, chiamiamolo utente #1234, per il quale vale quanto segue:
SELECT * FROM posts WHERE user_id=1234 restituisce due voci nella tabella. Questi sono i post che sono anche elencati nella pagina dell’attività del profilo dell’utente.
Il payload del webhook, quando questo utente accede o esce, contiene "post_count": 0.
Ho testato e il conteggio dei post non viene aggiornato in tempo reale.
La mia ipotesi è che ci sia un job Sidekiq che se ne occupi periodicamente, ma non so quale.
Non sembra esserci un job Sidekiq specifico correlato
Ma ho letto che questa statistica viene aggiornata almeno una volta al giorno.
Forse c’è una confusione tra “topics” e “posts”. Mi aspettavo che la creazione di un nuovo argomento fosse solo un tipo speciale di post. La struttura del database lo supporta.
Ma controllando le statistiche del profilo utente, dicono qualcosa del tipo “2 argomenti creati, 0 post creati”.
Quindi forse il “post_count” che ottengo è piuttosto il numero di risposte agli argomenti piuttosto che il numero di tutti i post?
D’altra parte, c’è una data “last_posted_at” che contiene la data in cui è stato creato l’ultimo argomento. Quindi almeno, c’è una certa incoerenza nella denominazione qui. Mi aspetterei che il numero “post_count” includa anche i primi post nei nuovi argomenti.
Comunque, che questo sia il comportamento previsto o meno, non trovo un topic_count o simile nel json dell’utente. Come faccio a scoprire il numero totale di post, inclusi i nuovi argomenti?