Gmail API Watch 未按标签过滤

Posted 2023-03-25

【中文标题】Gmail API Watch 未按标签过滤

【英文标题】：Gmail API Watch not filtering by Label

【发布时间】：2015-08-15 23:07:28

【问题描述】：

我正在将 Gmail 推送通知与 Google PubSub 一起使用，并且有一个我想要监控任何更改的自定义标签。我使用以下代码为标签注册手表（标签的Id为Label_1）

WatchRequest wr = new WatchRequest();
wr.TopicName = "projects/" + primaryLink.ggProjectId + "/topics/iLink" + segmentId;
if (labels != null && labels.Count > 0)

    wr.LabelIds = new List<string>();
    wr.LabelIds.Add("Label_1");
    wr.LabelFilterAction = "include";


WatchResponse wrr = gs.Users.Watch(wr, emailAccount).Execute();
return "HistoryId " + wrr.HistoryId.ToString();

手表注册正常。问题是我会收到任何 Gmail 更改的推送通知，而不仅仅是标签下的更改。

是否支持自定义标签？

【问题讨论】：

用户标签也应该可以正常工作。您确定不是对也有Label_1的消息进行了不同的标签更改吗？ （例如，Label_1 消息被标记为未读，但该消息上的 Label_1 未更改。）

例如在发送电子邮件时不会发生 - 这与标签无关。最初有一个未指定标签的用户手表。新的监视命令（带有标签过滤器）是否会覆盖以前的监视？我还尝试在新命令之前调用 Stop()？

一个 watch() 应该覆盖前一个。您可以调用 stop() 并将其保留一段时间以确保旧的已消失（在这种情况下，新的 watch() 不会覆盖旧的将是一个错误）。

我可以确认这仍然在 v1 中发生。

@PNC 此错误有一个谷歌问题跟踪器条目。您能否通过引用issuetracker.google.com/issues/36759803 来更新您的帖子，并附上注释来为该问题加注星标？为它加注星标的人越多，它就越早得到修复。

【参考方案1】：

我注意到了同样的问题，但后来发现这是因为 API 的工作方式。您可以通过 LabelIds 过滤电子邮件，但只有当电子邮件被直接过滤到选定的自定义标签时，您才会收到通知。我猜它的设计而不是 API 中的缺陷。

要对此进行测试，请在 Gmail 中创建一个自定义过滤器，它将您的自定义标签直接应用于一组电子邮件，您应该会收到这些电子邮件的通知。

已编辑（2015 年 6 月 11 日）： 推送通知会向您发送 HistoryID 和用户的邮箱名称。作为响应，您的端点应该调用 userhistory.list() 并带有您想要监控更改的 HistoryID 和 LabelId。

$opt_param = array();
$opt_param['startHistoryId'] = $historyID;
$opt_param['labelId'] = $labelID;
$opt_param['fields'] = 'nextPageToken,historyId,history/messagesAdded';

$service->users_history->listUsersHistory($userID, $opt_param);

上面是一个 php 代码 sn-p 用 historyID 和 labelID 过滤历史列表。

【讨论】：

@PNC 问题是 watch() 钩子只为您获取每个事件的 HistoryID 和邮箱，无论您在创建监视请求时指定什么 LabelId。 historyID 是邮箱范围的 ID，而不是 LabelID 范围的。因此，无论标签的任何内容发生变化，HistoryID 都会递增。为了响应推送通知，您的端点应该调用 historyList.list()。在这里您可以过滤带有您想要监控的 labelID 的消息。

我从 Google 团队之一那里获得了以下更新：“您应该能够像您指定的那样通过标签 ID 限制 watch()，但我可以确认它不起作用现在为 user 标签。逻辑和错误相当复杂，我们正在努力，但没有 ETA"

Google 曾经修复过这个问题吗？我仍然有同样的问题，过滤器不起作用。

截至 2020 年 1 月 20 日仍然存在问题。浪费了一整天的工作。是的

截至 2020 年 4 月 18 日仍有问题