[notifications]: Implement location.feed_added notification type

オープン
  • 何か問題がありますか？
#1,725 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
68/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
python
領域
backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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
主要言語
Python
スター
34
フォーク
7
平均マージ
3日 19時間
マージ済み PR（30日）
8

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

MobilityData/mobility-feed-api のほかの issue

MobilityData/mobility-feed-api の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。