Campaign dispatch recheck ignores allow_unverified: recipients skipped as 'unverified' at claim time
メンテナーはふだん 1 日以内に返信
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 72/100
調査の方向性
mailing/services/campaign_sender.py::_suppression_reasons、suppression.py::suppression_skip_reason、およびmailing/services/campaigns.py::_annotate_snapshot_skipのスナップショットゲートを読みます。配信時の再チェックにキャンペーンのコンテキストを渡し、allow_unverifiedが未検証の理由だけを回避することを確認してください。ハードバウンス、苦情、配信停止、無効なメールアドレスの検証結果は引き続き抑制される必要があります。両方のケースについてテストを追加または更新し、許可された未検証の宛先がclaim時にスキップされないことを確認してください。
索引モデルが issue の本文から書いたものです。
説明
Evidence (production, 2026-11-11 01:32 UTC)
An API campaign queued with allow_unverified: true (recipient_list_key aishl-test-21-…, 200 recipients) finished dispatch in ~4s with status=sent and all 200 campaign_recipients status=skipped, skip_reason='unverified', zero SES message ids, zero counters. The snapshot annotation honored the flag (recipients created as pending candidates), but the worker's suppression recheck skipped every one at claim time.
Root cause
mailing/services/campaign_sender.py::_suppression_reasons calls suppression.py::suppression_skip_reason(contact, …), which returns UNVERIFIED whenever neither the contact nor its audience/client subscription has verified_at — it never sees campaign.allow_unverified. The snapshot-time annotation (mailing/services/campaigns.py::_annotate_snapshot_skip, line ~236) correctly gates the UNVERIFIED rule on if not campaign.allow_unverified, so the flag is only half-implemented: allowed at snapshot, ignored at dispatch.
Suggested fix
_suppression_reasons has the campaign in scope; pass it through and skip the UNVERIFIED branch when campaign.allow_unverified is set (mirroring the snapshot gate). Suppression for hard bounces, complaints, unsubscribes and invalid email validation should stay unconditional.
Impact
Any API client using allow_unverified campaigns (the documented partner for recipient_list_key sends — the flag is even required to be paired with a recipient list) silently sends to nobody. The AISHL website's guarded internal bulk proof depends on it; a website-side workaround (verifying contacts at upsert) shipped in AI-Shipping-Labs/website#2085 as a stopgap.
- 主要言語
- Python
- スター
- 0
- フォーク
- 0
- 平均マージ
- 26分
- マージ済み PR（30日）
- 58
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
DataTalksClub/relay のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
DataTalksClub/relay#48 ·
メンテナーはふだん 1 日以内に返信
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
DataTalksClub/relay#49 · コメント 3 件 ·
メンテナーはふだん 1 日以内に返信
-
bug
難易度 5/5 1週間以上 初心者へのやさしさ 20/100
DataTalksClub/relay#42 · コメント 7 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 15/100
DataTalksClub/relay#41 · コメント 9 件 ·
メンテナーはふだん 1 日以内に返信
-
community-base enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 25/100
DataTalksClub/relay#39 · コメント 6 件 ·
メンテナーはふだん 1 日以内に返信
DataTalksClub/relay の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
btclib-org/btclib#3062 ·
メンテナーはふだん 1 日以内に返信
-
area:evals area:infra enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
jse-avl/support-bot#4 · コメント 1 件 ·
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
qte77/agentic-job-offer-to-application-kit#487 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
btclib-org/btclib-wallet#801 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
documentation good first issue
難易度 1/5 1〜3時間 初心者へのやさしさ 94/100