[notifications]: Implement feed.url_availability notification type
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- python
- Área
- backend-api-design
Línea de trabajo
Start by reading the existing feed availability monitoring and notification dispatcher flows; the issue does not name specific files or tests. Trace how availability changes are detected and how notification_event, notification_subscription, and notification_log are used. Done means unavailable and recovery transitions each create one event and the dispatcher records delivery per event, subscription, and channel.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the problem
Implement the feed.url_availability notification type for cases where a feed URL becomes unavailable or comes back online. This should detect availability state changes, build the notification payload for subscribed users, and integrate with the notification dispatcher.
Proposed solution
When a feed URL becomes unavailable for 7 days
Use feed availability monitoring as the source of truth for the feed.url_availability notification.
A notification should be created only when the feed URL changes from available to unavailable, not every time a feed check fails. The event should include the feed ID, feed URL, HTTP status code or error reason, first failure time, latest checked time, and availability status.
To support this:
Notification event table
When the system detects that a feed has become unavailable, create a notification_event record with notification_type = feed.url_availability and event_type = became_unavailable.
When a feed URL comes back online
Use the same feed availability monitoring data as the source of truth when a feed URL changes from unavailable to available.
The notification should explain that the feed URL is available again and include the outage period when possible.
To support this:
Notification event table
When the system detects that a previously unavailable feed is available again, create a notification_event record with notification_type = feed.url_availability and event_type = became_available. The event should include the feed ID, feed URL, recovery time, previous failure reason, and outage duration if available.
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 availability event. The dispatcher should match the event to active notification_subscription records and create/update one notification_log per notification_event_id + subscription_id + channel.
Alternatives you've considered
Timestamp-based detection
Use last_notified_at on notification_subscription and query feed availability records updated after that timestamp. This is simpler, but it risks missed or duplicated notifications if the dispatcher fails or if multiple availability changes happen between runs.
Additional context
Suggested notification code:
feed.url_availability
Suggested event_type values:
became_unavailablebecame_available
- Lenguaje dominante
- Python
- Estrellas
- 34
- Forks
- 7
- Merge medio
- 2 d 4 h
- PR fusionados (30 d)
- 8
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
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de MobilityData/mobility-feed-api
-
fix(notifications): dispatcher ignores a subscription's feeds and sends every feed.url_updated eventAbierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
MobilityData/mobility-feed-api#1875 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
MobilityData/mobility-feed-api#1846 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
MobilityData/mobility-feed-api#1755 · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
MobilityData/mobility-feed-api#1647 ·
Los mantenedores suelen responder en 1 día
-
enhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
MobilityData/mobility-feed-api#836 ·
Los mantenedores suelen responder en 1 día
Todos los issues de MobilityData/mobility-feed-api
Issues similares
-
bug
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
sergey-miryanov/gcmon#230 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Azure-Samples/azure-search-openai-demo#3249 ·
Los mantenedores suelen responder en 1 día
-
[BUG] Failed archive extraction deletes the dataset cachePosiblemente ocupada @dajiaohuang la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
alibaba/GraphScope#4674 ·