Resumen

  • Un estado completo, una modificación parcial y un aviso para consultar datos tienen necesidades distintas de conservación. Agruparlos por la misma etiqueta no elimina esas diferencias.
  • La sustitución Web Push cambia también la duración, la urgencia y la solicitud de confirmación del mensaje pendiente. No retira un contenido que ya está en camino.
  • La aplicación debe definir qué información puede perderse sin borrar una obligación y qué fuente permitirá reconstruir el trabajo cuando el usuario vuelva.

Un expediente puede tener una sola referencia y varias tareas pendientes. Que todas las notificaciones lleven esa referencia facilita reconocer el expediente; no significa que la última tarea asignada deje sin efecto las anteriores. Esta distinción resulta evidente en una conversación entre personas. Es menos visible cuando se convierte en una regla para reducir una cola de mensajes.

Imaginemos una herramienta de coordinación que avisa a un usuario de dos revisiones distintas. El dispositivo no está disponible. Si el segundo aviso reemplaza al primero porque ambos pertenecen al mismo expediente, el servicio de entrega puede haber ejecutado correctamente la instrucción recibida. Sin embargo, la primera revisión sigue existiendo. Solo sería seguro omitir su aviso si el usuario conserva una forma suficiente de descubrirla y atenderla.

Ahora supongamos que cada notificación contiene la lista completa y actualizada de revisiones pendientes. Una lista posterior puede volver innecesaria a la anterior. El resultado depende de que sea realmente completa, de que corresponda a una versión más reciente y de que el receptor pueda interpretarla. La referencia común no demuestra ninguna de esas condiciones.

Estos ejemplos son hipotéticos. No describen una pérdida documentada de tareas ni un defecto de un proveedor. Sirven para precisar el problema económico: evitar trabajo de entrega redundante es valioso; eliminar información que solo parece redundante puede trasladar trabajo a otro lugar.

Tres mensajes parecidos, tres compromisos diferentes

La palabra «actualización» oculta diseños muy distintos. Puede significar «este es el estado completo», «aplica este cambio» o «consulta el estado disponible en otra parte». Antes de decidir qué mensajes pueden desaparecer, conviene saber cuál de esas promesas recibe el usuario.

Una descripción completa puede sustituir otra si conserva todo lo necesario para la tarea. No tiene por qué conservar toda la historia. Un panel cuyo propósito es mostrar la situación actual puede funcionar mejor sin obligar al dispositivo a procesar cada estado intermedio.

Una modificación parcial depende de lo que ya conoce el destinatario. Si cada mensaje añade una tarea, omitir uno no produce automáticamente una lista actualizada: puede producir una lista incompleta. Si cada mensaje expresa un incremento o una reducción, conservar solo el último tampoco equivale a calcular el resultado de todos. El transporte no realiza esa operación por el mero hecho de agrupar mensajes.

Un aviso para consultar datos sitúa la memoria en otro sistema. Puede bastar un único aviso después de varios cambios si la consulta devuelve lo que el usuario necesita. El ahorro es real cuando se evita repetir información que sigue disponible. Pero debe incluirse el costo de mantener accesible esa fuente y de utilizarla al recuperar la actividad.

La diferencia importa incluso si las tres variantes muestran exactamente el mismo texto breve en pantalla. Una frase como «hay novedades en el expediente» no revela si detrás existe una lista completa, una secuencia de cambios recuperable o solo el último evento. La interfaz puede simplificar la presentación sin resolver la conservación.

Tampoco toda aplicación necesita un archivo de cada transición. Exigirlo indiscriminadamente puede añadir almacenamiento, controles de acceso y trabajo de soporte que el producto no requiere. La pregunta más útil es concreta: después de perder este mensaje, ¿puede el destinatario conocer y realizar todo lo que su tarea todavía exige?

Lo que autoriza Topic

La RFC 8030, publicada en diciembre de 2016, define la sustitución de mensajes Web Push pendientes. Dentro de una misma suscripción, un mensaje nuevo puede desplazar otro que tenga el mismo Topic. Se crea un recurso nuevo y se elimina simultáneamente el recurso anterior correspondiente. El campo permite correlacionar mensajes, sin atribuirles otro significado de aplicación.

Por tanto, Topic no es una instrucción para sumar cambios, comprobar obligaciones o elegir la versión de negocio más reciente. El servicio puede hacer coincidir dos valores sin conocer el expediente. Esa separación permite una función de transporte limitada y útil, pero deja la decisión sobre equivalencias en manos de quien genera los mensajes.

Un grupo demasiado amplio puede mezclar tareas independientes. Uno demasiado estrecho puede impedir que se eliminen actualizaciones realmente superadas. No existe una respuesta universal basada en usar siempre el identificador del usuario, del expediente o de cada evento. La unidad apropiada depende del contenido y de la forma de recuperación.

La norma limita la etiqueta a treinta y dos caracteres del alfabeto Base64 seguro para URL y nombres de archivo; un valor no válido requiere una respuesta 400. Cumplir esa restricción asegura una propiedad de formato, no la corrección de la agrupación. Una etiqueta perfectamente válida puede expresar una política equivocada para el trabajo.

La coordinación entre productores merece especial atención. Si un componente envía resúmenes completos y otro envía cambios parciales con el mismo Topic, la sustitución puede combinar dos promesas incompatibles. El problema no exige que ninguno de los componentes esté averiado: basta con que atribuyan significados diferentes a una convención compartida.

Este es un riesgo de diseño inferido del mecanismo, no una incidencia observada. Su solución no tiene por qué ser conservar todo. Puede consistir en separar grupos, hacer coherente el contenido o mantener la información necesaria en una fuente de consulta. Elegir entre esas opciones requiere entender la tarea, no solo medir el tamaño de la cola.

No solo cambia el texto

La sustitución descrita por la RFC también reemplaza la duración de vida, la urgencia y la suscripción a confirmaciones de entrega asociadas al mensaje pendiente. Conservar el contenido considerado más reciente no significa conservar las condiciones anteriores de entrega.

Esto permite ajustes razonables. Una situación que ya no requiere la misma atención puede justificar una urgencia menor. Una descripción que pronto dejará de ser útil puede justificar una espera más corta. Pero la misma diferencia puede proceder de valores predeterminados incoherentes entre productores.

Si un aviso de menor urgencia reemplaza otro de mayor urgencia, puede cambiar su elegibilidad cuando el agente usuario filtra por ese parámetro. Si la duración se acorta, puede terminar antes la oportunidad de iniciar la entrega. Revisar únicamente el texto no permite saber si la modificación representa una nueva situación o un cambio accidental de política.

Además, la duración solicitada no garantiza almacenamiento incondicional. El servicio puede reducirla y no debe iniciar nuevos intentos una vez vencida. El tiempo de tránsito no queda enteramente incorporado a ese cálculo. La RFC contempla también la expiración anticipada por restricciones operativas, con comunicación del fallo cuando se pidió una confirmación.

Para la aplicación, esto refuerza la necesidad de evaluar la recuperación. Una notificación que pide consultar una lista puede tolerar su propia desaparición de manera distinta de una notificación que contiene la única descripción de una tarea. No porque la primera vaya a entregarse siempre, sino porque su diseño puede ofrecer otro camino para volver a un estado suficiente.

La RFC 8291 añade una separación relevante: el cifrado de contenido Web Push no incluye las cabeceras HTTP. El destinatario debe tratarlas como procedentes del servicio push. TLS sigue protegiendo el transporte frente a terceros; no se afirma aquí que el tráfico quede expuesto libremente.

En consecuencia, una cabecera de entrega no debería confundirse con una declaración autenticada de la lógica de negocio. Si el receptor necesita identificar un expediente, comprobar una versión o entender una acción, esa información debe tener una ubicación adecuada en el diseño de la aplicación. El cifrado del cuerpo no convierte Topic en una prueba de que dos obligaciones sean equivalentes.

Lo que salió de la cola no vuelve por reemplazarlo

Una segunda limitación aparece cuando el destinatario comienza a recibir el mensaje anterior antes de la sustitución. La RFC contempla que su confirmación llegue después y recomienda suprimir las confirmaciones correspondientes al mensaje eliminado. No recibir ese comprobante no demuestra que el contenido anterior nunca haya llegado.

Esto afecta a las instrucciones con consecuencias. Si el mensaje anterior ya desencadenó trabajo, sustituir la entrada pendiente no deshace ese trabajo. Un producto que necesita cancelar una instrucción debe definir cómo se comunica y ejecuta esa cancelación; no puede atribuírsela a una operación sobre una cola.

También puede haber una discrepancia entre el orden de llegada y el de las revisiones. Un productor demorado puede enviar después una descripción más antigua. Al comparar etiquetas, el servicio no interpreta versiones de negocio dentro del contenido cifrado. Mantener «el último» exige aclarar de qué orden se está hablando.

La aplicación puede coordinar productores, reconocer revisiones obsoletas en el receptor o consultar el estado de referencia. Son alternativas de diseño, no requisitos adicionales impuestos por la RFC. La opción adecuada para mostrar un estado puede ser insuficiente para una secuencia donde cada evento exige una acción distinta.

La pantalla no resuelve esta ambigüedad. El estándar Notifications de WHATWG describe la sustitución de notificaciones mediante un tag no vacío coincidente y el mismo origen, con diferencias según el soporte de reemplazo de la plataforma. Es otro ámbito: presentación en el dispositivo, no correlación de mensajes pendientes dentro de una suscripción.

La RFC exige que Topic no se reenvíe al agente usuario. Por ello, la aplicación no recibe automáticamente esa etiqueta como tag de visualización. Si quiere coordinar ambas decisiones, debe hacerlo explícitamente. Una sola tarjeta visible puede representar muchas tareas; la desaparición de otra tarjeta no certifica que alguna haya quedado resuelta.

El borrador de trabajo Push API de W3C del 1 de diciembre de 2025 distingue una ruta ordinaria con service worker y otra de notificación declarativa. Su algoritmo de recepción contempla también confirmaciones tras ciertos fallos, incluidos problemas de descifrado o fallos repetidos del evento. Esas confirmaciones ayudan a terminar intentos; no acreditan por sí mismas un resultado de negocio.

Se trata de un borrador, no de una afirmación sobre la implementación de todos sus caminos en cada navegador. Este análisis no incluye pruebas de interoperabilidad ni mediciones de una aplicación concreta. La diferencia entre conservar, entregar, mostrar y actuar se apoya en el alcance de los mecanismos, sin inventar datos de despliegue.

La unidad económica es el trabajo recuperable

La sección 7.4 de la RFC 8030 considera el uso eficiente de la radio junto con los costos de retransmisión, consulta y resincronización. Los contadores de mensajes sin leer que quedan rápidamente superados ilustran por qué no siempre conviene enviar todos los valores intermedios.

De ahí no se deduce un porcentaje de ahorro energético ni una recomendación universal de sondeo. El balance depende de cuánto evita la sustitución y de cuánto cuesta recuperar lo que el destinatario necesita. Reducir entregas puede ser una mejora, una transferencia de costos o una pérdida de información; contar mensajes no distingue esos resultados.

Una evaluación útil sigue el expediente hasta la vuelta del usuario. ¿Encuentra todas sus tareas? ¿Comprende qué estado es vigente? ¿Debe pedir a otra persona que reconstruya lo ocurrido? ¿El resumen le permite llegar a los detalles? Son preguntas sobre el producto, aunque la decisión inicial aparezca como una optimización de infraestructura.

El criterio final no es que sobreviva cada aviso. Es que sobreviva una forma adecuada de conocer y hacer lo necesario. Dos mensajes pueden compartir referencia sin compartir destino: uno puede haber quedado obsoleto; el otro puede seguir representando una obligación.