[notifications]: Implement location.feed_added notification type

Abierto
  • ¿Algo no está bien?
#1,725 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
68/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
backend-api-design

Línea de trabajo

Find where feed-location relationships are created to hook the notification event creation. Look at existing notification event types to understand the pattern for creating notification_event records with notification_type = 'location.feed_added'. Examine the dispatcher that queries new events and matches them to notification_subscription records to create notification_log entries. The event should include feed ID, name/provider, data type, location ID, name, country/region, and creation time.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Describe the problem

Implement the location.feed_added notification type for cases where a feed is added to a location in the Mobility Database. Members want to be notified when new feed coverage becomes available for a location they care about.

Proposed solution
When a feed is added to a location

Use the feed-location relationship as the source of truth for the location.feed_added notification.

A notification should be created only when a new relationship is created between a feed and a location, not when the feed or location is simply updated. The event should include the feed ID, feed name/provider, data type, location ID, location name, country/region if available, and creation time.

To support this:

Notification event table
When a feed is linked to a location, create a notification_event record with notification_type = location.feed_added. The dispatcher can then query new events, match them to active subscriptions, generate the digest based on cadence, and track delivery per user.

Tracking notifications per user

Use notification_event to track what happened, and notification_log to track delivery per user subscription.

Each notification_event should be created once for the new feed-location relationship. The dispatcher should match the event to active notification_subscription records and create/update one notification_log per notification_event_id + subscription_id + channel.

This allows the system to know which users already received the event, avoid duplicate notifications, and retry failed deliveries without resending to users who were already notified.

Alternatives you've considered
Timestamp-based detection

Use created_at on the feed-location relationship table and query relationships created after the last successful notification run. This is simpler, but it risks missed or duplicated notifications if the dispatcher fails or if delivery needs to be retried per user.

Additional context

Suggested notification codes:

  • location.feed_added
  • coverage.feed_added
  • feed.location_added
  • feed.location_added
  • feed.geography_added
Lenguaje dominante
Python
Estrellas
34
Forks
7
Merge medio
3 d 11 h
PR fusionados (30 d)
9

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de MobilityData/mobility-feed-api

Todos los issues de MobilityData/mobility-feed-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.