Esto es casi con toda seguridad obra de Discourse. Simplemente no envían notificaciones si has usado el sitio hace un cierto número de minutos. Pero sin forma de que los usuarios finales lo vean, simplemente hace que las notificaciones no sean confiables. Pero te aseguro que recibí notificaciones push de iOS para ambos mensajes. Pueden funcionar, siempre y cuando sepas que nunca debes confiar en ellas.
Creo que el problema es al revés. No usar el sitio en mi teléfono con suficiente frecuencia parece que deja de enviar notificaciones.
Quizás, pero todos estamos adivinando. Lo principal que necesitamos es que Discourse proporcione registros adecuados a los usuarios finales. ¿Qué notificaciones envió Discourse? ¿Qué notificaciones decidió Discourse no enviar?
Cuando la PWA recibe una notificación, se le permite registrarla localmente en IndexedDB en el dispositivo. Los usuarios deben poder ver ese registro y correlacionarlo con el registro del servidor, para ver cuándo/si Discourse envió el push pero el dispositivo no lo recibió.
Pero, en general, diría: no asumas que el problema es culpa de Apple, y especialmente no asumas que solo esperar iOS 18 ayudará. Necesitamos que Discourse trabaje aquí, o nada mejorará.
Esto me parece un registro muy, muy detallado:
Un registro detallado aquí, probablemente sea bastante fácil:
"Se omitió notificar a Sam sobre “payload” porque Sam estaba en línea.
Pero si solo quieres depurar esto, ¿por qué no estableces SiteSetting.push_notification_time_window_mins en 0?
Y entonces el siguiente nivel de registro se vuelve muy, muy detallado:
- Se omitió la notificación porque el usuario tenía la opción de no molestar activada
- Tiempo de espera para el proveedor de notificaciones push discourse/app/services/push_notification_pusher.rb at cacaa90f4d01452358322ea8b5564f15f4816c74 · discourse/discourse · GitHub
- Suscripción caducada
- Error de respuesta
Pueden ocurrir muchas cosas diferentes… aunque en cualquier momento probablemente puedas usar DE para validar: busca en la tabla push_subscriptions las suscripciones web push actualizadas.
1 me gusta
Permítanme empezar diciendo que, desde mi punto de vista, el problema es que la gente escribe aquí y en mi foro diciendo: “Creo que las notificaciones push no funcionan bien”, y otros usuarios intervienen diciendo: “¡Sí! ¡Yo también! Las notificaciones deben estar rotas/no ser fiables”. A veces culpan a Apple, a veces culpan a Discourse, pero todos coinciden en que las notificaciones push de Discourse no son fiables.
Me encantaría poder investigar estos casos yo mismo, diciendo “no recibiste la notificación de las 12:31 p.m. en tu teléfono, y aquí está el porqué…”, pero no creo que eso sea posible actualmente.
Sí, pueden salir mal muchas cosas diferentes, incluidas cosas del lado del cliente, que no puedo investigar en DE.
- ¿El Service Worker recibió el evento push?
- ¿El Service Worker llamó a
showNotification? - ¿Se concedió el permiso para
showNotification, oshowNotificationno hizo nada? - ¿El dispositivo en sí estaba configurado en No Molestar?
Me encantaría tener alguna documentación para los administradores que explique cómo usar DE para diagnosticar un fallo de push, al menos en lo que respecta a ver si la notificación se envió correctamente.
Pero también sería increíblemente útil mantener un registro del lado del cliente que los usuarios pudieran enviarme, lo que me permitiría cruzarlo con el registro de DE.
Por un lado, al menos la mitad de las personas que se quejan de esto no son administradores de su foro. Es por eso que necesitamos que Discourse implemente esto:
Pero, sí, sospecho que establecer esto a 0 eliminará el 80% de las quejas de “no funciona”.
En general, la confianza de los usuarios en las notificaciones de Discourse es bastante baja. Cuanto más investigable sea este problema, para los administradores (e incluso para los usuarios finales), más confiables serán las notificaciones de Discourse.
4 Me gusta
Estoy un poco confundido con esta parte, enviamos a una URL directamente desde el servidor…
Aquí está mi razonamiento. Mira lo que dicen los usuarios en este hilo.
Estas publicaciones parecen implicar que el problema podría ser culpa de Apple. ¿Quizás Discourse está enviando a la URL, pero luego, por alguna razón, Apple no está entregando el push? ¿Por qué podría ser eso?
- ¿Quizás Apple está devolviendo 4xx o 5xx al trabajo de push, y Discourse necesita volver a enviarlo?
- ¿Quizás Apple recibió el mensaje, pero no puede (¿o no quiere?) entregarlo al dispositivo?
- ¿Quizás el dispositivo recibió el mensaje, pero Apple no está activando el evento
pushpara el service worker? - ¿Quizás el service worker recibió el evento
push, pero hay un error y no llamó ashowNotification(probablemente no este, sería demasiado obvio…?)? - ¿Quizás el service worker recibió el evento
pushy llamó ashowNotification, pero Apple se negó a mostrar una notificación visible? De hecho, hay muchas razones por las que esto podría suceder:- El dispositivo está configurado en No molestar (pero la notificación debería aparecer eventualmente en el Centro de notificaciones, en ese caso, creo).
- El permiso se concedió en algún momento, pero ahora está revocado (¡la PWA puede detectar este caso y registrarlo!).
- El usuario podría haber configurado la aplicación con configuraciones de notificación extrañas, por lo que, por ejemplo, solo envía al Centro de notificaciones pero no muestra un banner.
- … ¿o Apple se niega a mostrar el mensaje por alguna otra razón de política (¿quizás piensan que la notificación es spam?), y tal vez sean más generosos en una futura versión de iOS?
Y eso sin tener en cuenta ninguna de las razones por las que el propio Discourse podría no enviar la notificación (No molestar, filtros de push, push_notification_time_window_mins).
Si todo lo que podemos decir es: “Bueno, a las 12:31 p.m., Discourse envió una notificación con el ID XXX a Apple, y Apple devolvió un código de estado 201 Created, pero no tenemos idea de lo que sucedió después”, entonces estos usuarios/administradores no tendrán forma de investigar más a fondo. Simplemente tendremos que culpar a Apple y renunciar a las notificaciones push. (“Quizás las notificaciones push web de iOS 18 en 2024 lo hagan”).
En cambio, necesitamos poder decir: “Tus registros en el dispositivo muestran que a las 12:33 p.m., el service worker se activó con un evento push para la notificación ID XXX, y llamó a showNotification, y podemos ver a través de la API de Notificaciones que Apple dice que se concedió el permiso para showNotification para ese push XXX”.
(También creo que debería haber un botón de “enviar una notificación de prueba” en la página https://meta.discourse.org/my/preferences/notifications que te permita programar una notificación en el futuro, por ejemplo, N minutos o N horas en el futuro, permitiendo a los usuarios probar el caso de “no funciona después de unas horas”).
3 Me gusta
Por mi parte, no pude reproducir esto en mi sitio de staging. Las notificaciones funcionan allí sin problemas. El problema es mi sitio de producción. Las notificaciones dejan de funcionar en unas pocas horas cada vez que las activo. Mi única teoría es que quizás el volumen de notificaciones push podría ser un problema. Mi sitio de producción es muy activo y tiene más de 50.000 miembros, por lo que se envían muchas notificaciones a mi cuenta de usuario (y en general).
Así que @WorldIsMine y yo hicimos un pequeño experimento.
- esperamos hasta que sus notificaciones dejaran de funcionar
- verificamos que su suscripción push todavía estuviera en la tabla
push_subscriptions
- envié una notificación push desde la consola de Rails y me aseguré de registrar todas las excepciones
u = User.find(1)
payload = { excerpt: "Test", "translated_title": "Test!" }
PushNotificationPusher.push(u, payload)
- no hubo ninguna excepción
- él no la recibió
- (para verificar, pude enviarme una notificación push a mí mismo)
Entonces, ¿esto es algo de Apple? ¿Qué podría ser?
5 Me gusta
¿Tienen acceso a una Mac para probar en Safari de macOS? Podrían configurar herramientas de desarrollo para depurar el service worker allí.
1 me gusta
Según entiendo, aquí no hay ningún service worker involucrado.
No, todas las notificaciones push web requieren un service worker en iOS. Sending web push notifications in web apps and browsers | Apple Developer Documentation
Ok, está fuera de mi alcance, lamentablemente no tengo experiencia con esto en el lado del cliente, y no tengo Mac a mi disposición.
Al menos hemos descartado el lado del servidor.
¡Ajá! Creo que he descubierto al menos un error con esto, registrado en un hilo separado.
7 Me gusta
Aunque esperaba que tu arreglo mejorara las cosas, no estoy seguro.
Meta ha sido implementada con él durante una semana. Habilité las notificaciones en vivo en mi PWA de iPhone. Hoy… simplemente dejaron de funcionar.
Fue creado el 5 de enero.
Intentaré depurar esto con un script para ver qué lo provoca y cuánto dura, pero mucho apunta aquí hacia Apple simplemente teniendo un error de algún tipo.
Cuanto más lo pienso, más creo que Discourse Hub es la solución ahora para los dispositivos Apple.
3 Me gusta
¡Gracias por hacer el seguimiento!
¿Has hecho clic en alguna notificación? Lo pregunto porque me pregunto si Apple desactiva automáticamente las notificaciones web si has recibido un cierto número de ellas sin hacer clic en ninguna.
1 me gusta
Todavía necesitamos estas funciones para analizar los fallos:
- Instrucciones sobre cómo usar el Explorador de datos para ver el historial de notificaciones push.
- Registros en el dispositivo, para que podamos extraerlos y correlacionarlos con los registros del lado del servidor.
Los registros deben incluir las marcas de tiempo de todos los eventospush, incluido el payload completo, así como el estado deNotification.permission. - Botón “Enviar una notificación de prueba” que ponga en cola una notificación para N minutos/horas en el futuro.
6 Me gusta
Tenga en cuenta que las notificaciones de mi PWA han estado funcionando de manera constante durante las últimas 3 semanas en meta.
8 Me gusta
Aquí hay una actualización preocupante, que indica que nos esperan más problemas en este frente:
3 Me gusta
Para tu información, la noticia que @nathank informó anteriormente ha sido completamente confirmada por Apple.
En un acto de cumplimiento descaradamente malicioso de la Ley de Mercados Digitales de la Unión Europea, que tiene como objetivo aportar más apertura y competencia a las plataformas digitales, Apple ha decidido eliminar las PWA en la UE con su próxima versión de Safari iOS 17.4.
Esto impedirá la instalación de PWA en la pantalla de inicio, el uso de notificaciones push, la sincronización en segundo plano e interferirá con el almacenamiento sin conexión y más. Y tendrá un impacto global más allá de la UE, dado que las empresas estarán mucho menos dispuestas a invertir en aplicaciones web, y en particular en PWA, si los usuarios de iPhone en la UE no pueden utilizarlas.
Tengo que suponer que esto será un gran obstáculo para muchas comunidades de Discourse, y para Discourse en sí. Si este es tu caso, te recomiendo encarecidamente que completes esta encuesta del grupo Open Web Advocacy. Ellos lideran la lucha contra esto, trabajando para informar al equipo de la DMA sobre todas las implicaciones de estas y otras políticas en el desarrollo web. Están tratando urgentemente de recopilar testimonios y datos de empresas que se verán afectadas por estos cambios, para poder proporcionar a la DMA mejor información para contraatacar.
¡Visita esta página para obtener más información, completa su encuesta sobre cómo esto afecta a tu negocio y corre la voz! Sería particularmente excelente si Discourse pudiera informar a sus usuarios sobre el próximo cambio, para que cada uno de ellos pueda conectarse con OWA para explicar cómo esto afecta a sus negocios y comunidades.
7 Me gusta