[notifications]: Implement feed.url_availability notification type
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Tranquilla
- Stack tecnologico
- python
- Ambito
- backend-api-design
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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
- Lingua principale
- Python
- Stelle
- 34
- Fork
- 7
- Merge medio
- 2g 4h
- PR unite (30g)
- 8
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Nessuna guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MobilityData/mobility-feed-api
-
fix(notifications): dispatcher ignores a subscription's feeds and sends every feed.url_updated eventAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
MobilityData/mobility-feed-api#1875 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
MobilityData/mobility-feed-api#1846 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
MobilityData/mobility-feed-api#1755 · 1 reazione ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
MobilityData/mobility-feed-api#1647 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
MobilityData/mobility-feed-api#836 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di MobilityData/mobility-feed-api
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
khuisman/mcp-gee-sweet#1166 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
lugassawan/swe-workbench#823 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
gramaziokohler/compas_timber#870 ·
-
security-scan-failure
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
semantica-agi/semantica#2089 ·
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 82/100
autowarefoundation/autoware_carla_scenario#500 ·
I maintainer di solito rispondono entro 1 giorno