Questo è quasi certamente solo un problema di Discourse. Semplicemente non inviano notifiche se hai utilizzato il sito un certo numero di minuti fa. Ma senza un modo per gli utenti finali di vederlo, le notifiche diventano inaffidabili. Ma ti assicuro, ho ricevuto notifiche push iOS per entrambi questi messaggi. Possono funzionare, purché tu sappia di non fidarti mai di loro.
Penso che il problema sia il contrario. Non utilizzare il sito sul mio telefono abbastanza di recente sembra interrompere la ricezione di qualsiasi notifica.
Forse, ma stiamo tutti solo ipotizzando. La cosa principale di cui abbiamo bisogno è che Discourse fornisca un logging adeguato agli utenti finali. Quali notifiche ha inviato Discourse? Quali notifiche Discourse ha deciso di non inviare?
Quando la PWA riceve una notifica, le è consentito registrarla localmente in IndexedDB sul dispositivo. Gli utenti devono essere in grado di visualizzare quel log e metterlo in correlazione con il log del server, per vedere quando/se Discourse ha inviato la notifica push ma il dispositivo non l’ha ricevuta.
Ma, nel complesso, direi: non dare per scontato che il problema sia colpa di Apple, e soprattutto non dare per scontato che aspettare iOS 18 aiuterà. Abbiamo bisogno che Discourse faccia del lavoro qui, altrimenti nulla migliorerà mai.
Questo mi sembra un logging molto verboso:
Un log verboso qui, probabilmente è abbastanza semplice:
"Saltata la notifica a Sam riguardo a "payload" perché Sam era online.
Ma se vuoi solo eseguire il debug di questo, perché non impostare SiteSetting.push_notification_time_window_mins a 0?
E poi il livello successivo di logging diventa molto, molto verboso:
- Saltata la notifica perché l’utente aveva abilitato non disturbare
- Timeout del provider di notifiche push discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- Sottoscrizione scaduta
- Errore di risposta
Molte cose diverse possono andare storte… anche se in qualsiasi momento puoi probabilmente usare DE per convalidare: cerca nella tabella push_subscriptions le sottoscrizioni web push aggiornate.
Vorrei iniziare dicendo che, dal mio punto di vista, il problema è che le persone scrivono qui e sul mio forum, dicendo “Penso che le notifiche push non funzionino correttamente”, e altri utenti intervengono dicendo: “Sì! Anch’io! Le notifiche devono essere rotte/inaffidabili”. A volte incolpano Apple, a volte incolpano Discourse, ma tutti concordano sul fatto che le notifiche push di Discourse siano inaffidabili.
Mi piacerebbe poter indagare su questi casi da solo, dicendo “non hai ricevuto la notifica delle 12:31 sul tuo telefono, ed ecco perché…” ma non credo che ciò sia attualmente possibile.
Sì, possono andare storte molte cose diverse, comprese cose sul lato client, che non posso indagare in DE.
- Il Service Worker ha ricevuto l’evento push?
- Il Service Worker ha chiamato
showNotification? - Il permesso
showNotificationè stato concesso, oshowNotificationnon ha prodotto alcun risultato? - Il dispositivo stesso era impostato su Non disturbare?
Mi piacerebbe avere della documentazione per gli amministratori che spieghi come usare DE per diagnosticare un fallimento push, almeno per quanto riguarda la verifica se la notifica è passata.
Ma penso che sarebbe anche incredibilmente utile mantenere un log lato client che gli utenti possano inviarmi, permettendomi di confrontarlo con il log DE.
Innanzitutto, almeno la metà delle persone che si lamentano di questo non sono amministratori del loro forum. Ecco perché abbiamo bisogno che Discourse implementi questo:
Ma, sì, sospetto che impostare questo a 0 eliminerà l’80% dei reclami “non funziona”.
Nel complesso, la fiducia degli utenti nelle notifiche di Discourse è piuttosto bassa. Più questo problema è ricercabile, per gli amministratori (e anche per gli utenti finali), più le notifiche di Discourse saranno affidabili.
Sono un po’ confuso riguardo a questo passaggio, inviamo a un URL direttamente dal server…
Ecco il mio ragionamento. Guarda cosa dicono gli utenti in questo thread.
Questi post sembrano implicare che il problema potrebbe essere colpa di Apple. Forse Discourse sta inviando all’URL, ma poi, per qualche motivo, Apple non sta inviando la notifica push. Come mai?
- Forse Apple sta restituendo 4xx o 5xx al job di push e Discourse deve riprovare.
- Forse Apple ha ricevuto il messaggio, ma non è in grado (o non vuole?) inviarlo al dispositivo.
- Forse il dispositivo ha ricevuto il messaggio, ma Apple non sta attivando l’evento
pushper il service worker. - Forse il service worker ha ricevuto l’evento
push, ma c’è un bug e non ha chiamatoshowNotification(probabilmente non questo, sarebbe troppo ovvio…?) - Forse il service worker ha ricevuto l’evento
pushe ha chiamatoshowNotification, ma Apple ha rifiutato di mostrare una notifica visibile. Ci sono in realtà molti motivi per cui ciò potrebbe accadere:- Il dispositivo è impostato su Non disturbare (ma la notifica dovrebbe apparire comunque nel Centro Notifiche, in quel caso, credo)
- Il permesso è stato concesso a un certo punto, ma ora è revocato (la PWA può rilevare questo caso e registrarlo!)
- L’utente potrebbe aver configurato l’app con impostazioni di notifica strane, quindi, ad esempio, invia solo al Centro Notifiche ma non mostra un banner
- … o Apple si rifiuta di mostrare il messaggio per qualche altro motivo di policy (forse pensa che la notifica sia spam?), e forse sarà più generosa in una futura versione di iOS
E questo senza considerare nessuno dei motivi per cui Discourse stesso potrebbe non inviare la notifica (Non disturbare, filtri push, push_notification_time_window_mins).
Se tutto ciò che possiamo dire è: “Bene, alle 12:31, Discourse ha inviato una notifica con ID XXX ad Apple, e Apple ha restituito un codice di stato 201 Created, ma non abbiamo idea di cosa sia successo dopo”, allora questi utenti/amministratori non avranno modo di indagare ulteriormente. Dovremo solo incolpare Apple e rinunciare alle notifiche push. (“Forse le notifiche push web di iOS 18 nel 2024 lo faranno.”)
Invece, dobbiamo essere in grado di dire: “I tuoi log sul dispositivo mostrano che alle 12:33, il service worker si è attivato con un evento push per la notifica ID XXX, e ha chiamato showNotification, e possiamo vedere tramite l’API delle Notifiche che Apple dice che il permesso di showNotification per quella notifica XXX è stato concesso.”
(Penso anche che dovrebbe esserci un pulsante “invia una notifica di test” sulla pagina https://meta.discourse.org/my/preferences/notifications che ti permette di programmare una notifica in futuro, ad esempio N minuti o N ore nel futuro, permettendo agli utenti di testare il caso “non funziona dopo qualche ora”.)
Dal mio punto di vista, non sono riuscito a riprodurre questo problema sul mio sito di staging. Le notifiche funzionano lì senza problemi. Il problema è il mio sito di produzione. Le notifiche smettono di funzionare dopo poche ore ogni volta che le attivo. La mia unica teoria è che forse il volume delle notifiche push potrebbe essere un problema? Il mio sito di produzione è molto attivo e ha oltre 50.000 membri, quindi molte notifiche vengono inviate al mio account utente (e in generale).
Così io e @WorldIsMine abbiamo fatto un piccolo esperimento.
- abbiamo aspettato che le sue notifiche smettessero di funzionare
- abbiamo verificato che la sua sottoscrizione push fosse ancora nella tabella
push_subscriptions
- ho inviato una notifica push dalla console rails e mi sono assicurato di registrare tutte le eccezioni
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- non c’è stata nessuna eccezione
- non l’ha ricevuta
- (per ricontrollare, sono riuscito a inviare una notifica push a me stesso)
Quindi è qualcosa da parte di Apple? Cosa potrebbe essere?
Avete accesso a un Mac per testare in Safari su macOS? Potreste configurare gli strumenti per sviluppatori per eseguire il debug della service worker lì.
Per quanto ne so, non c’è nessun service worker coinvolto qui.
No, tutte le notifiche push web richiedono un service worker su iOS. Sending web push notifications in web apps and browsers | Apple Developer Documentation
Ok, fuori dalla mia portata, sfortunatamente non ho esperienza con questo sul lato client, e non ho un Mac a disposizione.
Almeno abbiamo escluso il lato server della questione.
Aha! Penso di aver individuato almeno un bug, segnalato in un thread separato.
Per quanto sperassi che la tua correzione migliorasse le cose, non ne sono sicuro.
Meta è stato distribuito con esso per una settimana. Ho abilitato le notifiche live sulla mia PWA per iPhone. Oggi… hanno semplicemente smesso di funzionare.
È stato creato il 5 gennaio.
Proverò a eseguire il debug di questo con uno script per vedere cosa lo fa smettere di funzionare e per quanto tempo dura, ma molto indica qui verso Apple che ha semplicemente un bug di qualche tipo.
Più ci penso, più penso che Discourse Hub sia ora la soluzione per i dispositivi Apple.
Grazie per aver monitorato la situazione!
Hai cliccato su qualche notifica? Te lo chiedo perché mi chiedo se Apple disattivi automaticamente le notifiche web se ne hai ricevute un certo numero senza cliccarne nessuna.
Abbiamo ancora bisogno di queste funzionalità per analizzare i fallimenti:
- Istruzioni su come utilizzare Data Explorer per visualizzare la cronologia delle notifiche push.
- Log sul dispositivo, in modo da poter estrarre tali log e correlarli con i log lato server.
I log dovrebbero includere i timestamp di tutti gli eventipush, compreso il payload completo, nonché lo stato diNotification.permission. - Pulsante “Invia una notifica di test” che accoda una notifica per N minuti/ore nel futuro.
Nota, le mie notifiche PWA hanno funzionato in modo impeccabile per le ultime 3 settimane su meta
Ecco un aggiornamento preoccupante, che indica che ci aspettano altri guai su questo fronte:
Per tua informazione, la notizia che @nathank ha riportato sopra è stata pienamente confermata da Apple.
In un atto di sfacciata e malevola conformità al Digital Markets Act dell’Unione Europea, che mira a portare maggiore apertura e concorrenza alle piattaforme digitali, Apple ha deciso di eliminare le PWA nell’UE con il suo imminente Safari iOS 17.4.
Ciò impedirà l’installazione di PWA sulla schermata principale, l’uso delle notifiche push, la sincronizzazione in background e interferirà con l’archiviazione offline e altro ancora. E avrà un impatto globale oltre la sola UE, dato che le aziende saranno molto meno propense a investire in Web App, e in particolare in PWA, se gli utenti iPhone nell’UE non potranno utilizzarle.
Devo pensare che questo sarà un ostacolo importante per molte community di Discourse e per Discourse stesso. Se questo è il caso per qualcuno, consiglio vivamente di compilare questo sondaggio del gruppo Open Web Advocacy. Stanno guidando la lotta contro questo, lavorando per informare il team DMA di tutte le implicazioni di queste e altre politiche sullo sviluppo web. Stanno cercando urgentemente di raccogliere testimonianze e dati dalle aziende che saranno interessate da questi cambiamenti, in modo da poter fornire al DMA informazioni migliori per combattere.
Si prega di visitare questa pagina per saperne di più, compilare il loro sondaggio su come questo influisce sulla tua attività e spargere la voce! Sarebbe particolarmente eccellente se Discourse potesse rendere consapevoli i propri utenti del cambiamento imminente, in modo che ognuno di loro possa mettersi in contatto con OWA per spiegare come questo influisce sulle proprie attività e community.