Describe the problem
Implement the feed.coverage notification type for cases where a feed is close to expiring or has expired based on its latest dataset service coverage. This should detect coverage thresholds, build the notification payload for subscribed users, and integrate with the notification dispatcher.
Proposed solution
When feed coverage is close to ending
Use the latest dataset coverage information as the source of truth for the feed.coverage notification.
A notification should be created when the latest dataset coverage ends within a defined threshold, such as less than 7/14/30 days (TBD), . The event should include the feed ID, latest dataset ID, coverage end date, days remaining, and feed URL.
To support this:
Notification event table
When the system detects that a feed has less than the configured number of service coverage days remaining, create a notification_event record with notification_type = feed.coverage and event_type = expiring_soon.
When feed coverage has expired
Create a notification when the latest dataset coverage has already expired and no newer dataset is available.
The notification should explain that the feed may no longer represent active service. The event should include the feed ID, latest dataset ID, coverage end date, days since expiration, and feed URL.
To support this:
Notification event table
When the system detects that a feed has expired coverage, create a notification_event record with notification_type = feed.coverage and event_type = expired.
Producer follow-up notification
For producers, create a notification when a feed has been out of service for 30 days. The notification should ask the agency to provide an updated feed or corrected URL for the Mobility Database.
To support this:
Notification event table
When the threshold is reached, create a notification_event record with notification_type = feed.coverage and event_type = producer_follow_up_required. The event should include the feed ID, latest dataset ID, coverage end date, days expired, feed URL, and troubleshooting or update guidance.
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 coverage 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
Generate directly from dataset coverage during the dispatcher run
The dispatcher could query feeds with coverage ending soon or already expired and notify users directly. This is simpler, but it may send repeated warnings unless extra deduplication logic is added.
Additional context
Suggested notification code:
feed.coverage
Suggested event_type values:
expiring_soonexpiredproducer_follow_up_required
Describe the problem
Implement the
feed.coveragenotification type for cases where a feed is close to expiring or has expired based on its latest dataset service coverage. This should detect coverage thresholds, build the notification payload for subscribed users, and integrate with the notification dispatcher.Proposed solution
When feed coverage is close to ending
Use the latest dataset coverage information as the source of truth for the
feed.coveragenotification.A notification should be created when the latest dataset coverage ends within a defined threshold, such as less than 7/14/30 days (TBD), . The event should include the feed ID, latest dataset ID, coverage end date, days remaining, and feed URL.
To support this:
Notification event table
When the system detects that a feed has less than the configured number of service coverage days remaining, create a
notification_eventrecord withnotification_type = feed.coverageandevent_type = expiring_soon.When feed coverage has expired
Create a notification when the latest dataset coverage has already expired and no newer dataset is available.
The notification should explain that the feed may no longer represent active service. The event should include the feed ID, latest dataset ID, coverage end date, days since expiration, and feed URL.
To support this:
Notification event table
When the system detects that a feed has expired coverage, create a
notification_eventrecord withnotification_type = feed.coverageandevent_type = expired.Producer follow-up notification
For producers, create a notification when a feed has been out of service for 30 days. The notification should ask the agency to provide an updated feed or corrected URL for the Mobility Database.
To support this:
Notification event table
When the threshold is reached, create a
notification_eventrecord withnotification_type = feed.coverageandevent_type = producer_follow_up_required. The event should include the feed ID, latest dataset ID, coverage end date, days expired, feed URL, and troubleshooting or update guidance.Tracking notifications per user
Use
notification_eventto track what happened, andnotification_logto track delivery per user subscription.Each
notification_eventshould be created once for the coverage event. The dispatcher should match the event to activenotification_subscriptionrecords and create/update onenotification_logpernotification_event_id+subscription_id+channel.Alternatives you've considered
Generate directly from dataset coverage during the dispatcher run
The dispatcher could query feeds with coverage ending soon or already expired and notify users directly. This is simpler, but it may send repeated warnings unless extra deduplication logic is added.
Additional context
Suggested notification code:
feed.coverageSuggested
event_typevalues:expiring_soonexpiredproducer_follow_up_required