[Bug] Gmail trigger silently stops after 7 days: subscription expires_at is persisted as -1

快速结论：Dify 1.16.1 自托管（Docker）环境中，Gmail 触发器绑定 7 天后静默失效，因为持久化到数据库的 expires_at 为 -1（表示“永不过期”），导致定时刷新任务永远不会重新调用 Gmail users.watch。优先检查 trigger_subscriptions 表中该订阅的 expires_at 是否为 -1，并确认 Dify 版本是否已包含相关修复。

适用环境：Dify 1.16.1，Self Hosted（Docker 部署），Gmail Trigger 插件 langgenius/gmail_trigger 0.1.1。

最快修复方案：暂无确认的官方一步修复方案（Issue 已修复但未说明具体的版本发布计划）。临时可优先尝试：手动更新数据库 trigger_subscriptions 表中的 expires_at 为当前时间戳，以强制触发下一次刷新；或删除并重新创建该订阅。

注意事项：以上临时方案需要重启相关服务或等待刷新周期执行，且 Issue 作者确认 OAuth 凭证刷新不受影响，所以手动修改 expires_at 不会破坏凭证续期；但该操作属于临时绕过，版本升级后应验证是否仍需要该手动干预。

问题场景

用户在 Dify 1.16.1 中安装 langgenius/gmail_trigger 0.1.1 插件，创建订阅并绑定到已发布工作流的触发器节点。绑定后工作流能正常收到邮件，但在 7 天后（Gmail users.watch 租约的最长生命周期）触发器静默停止触发，下游所有组件（Pub/Sub 订阅、nginx 转发、认证刷新）均健康，但没有任何消息到达。

报错原文

[Bug] Gmail trigger silently stops after 7 days: subscription expires_at is persisted as -1

数据库查询结果（订阅创建后立即执行）：

       name        | expires_at |     watch_expires      |      cred_expires
-------------------+------------+------------------------+------------------------
 SES Mail Intake   |         -1 | 1969-12-31 23:59:59+00 | 2026-08-24 08:42:00+00

Worker 日志（每分钟执行，但从不调用 _refresh_subscription()）：

worker-1 | Begin subscription refresh: tenant=... id=f5f027d0-...
worker-1 | Refreshing OAuth token: subscription_id=f5f027d0-... expires_at=1787560681 now=1787557201
worker-1 | OAuth token refreshed: result={'result': 'success', 'expires_at': 1787560741}
worker-1 | Task tasks.trigger_subscription_refresh_tasks.trigger_subscription_refresh[...] succeeded

原因分析

可能原因：Dify 内部在 update_and_build_builder 函数中，TriggerManager.subscribe_trigger(...) 返回了包含真实 expires_at 的 Subscription 对象，但随后调用 add_trigger_subscription 持久化时误传了 subscription_builder.expires_at 而非 subscription.expires_at。由于 SubscriptionBuilder 初始化时 expires_at 被设置为 -1 且从未被更新，数据库中最终存储了 -1（按触发器插件规范表示“永不过期”）。定时刷新任务 _refresh_subscription_if_expired 检测到 expires_at == -1 时直接提前返回，因此 _refresh_subscription()（重新调用 Gmail users.watch）永远不被执行，7 天后租约静默失效。

另外，rebuild_trigger_subscription 路径已正确传递 expires_at=new_subscription.expires_at，所以重新创建订阅可以临时解决问题。

环境排查

确认 Dify 版本是否为 1.16.1（或更早版本，需自查是否包含修复提交）。
确认部署方式为 Docker（Self Hosted），且 worker 容器存在。
确认 langgenius/gmail_trigger 插件版本是否为 0.1.1（或检查更早版本是否存在同样问题）。
用 SQL 检查 trigger_subscriptions 表中订阅的 expires_at 和 credential_expires_at：若前者为 -1 而后者为正常时间戳，基本可定位为该问题。

解决步骤

临时方案（可优先尝试）：手动修正数据库中的 expires_at，使其小于当前时间戳，从而强制下一次刷新任务调用 _refresh_subscription() 重新创建 Gmail watch。例如：UPDATE trigger_subscriptions SET expires_at = extract(epoch from now())::int WHERE name = '你的订阅名';（注意备份数据，确认表名和列名与实际一致）。
备选方案：删除该订阅并通过界面重新创建，走 rebuild_trigger_subscription 路径，该路径已正确持久化真实的 expires_at。
升级修复：关注 Dify 官方 Release 说明，确认修复提交（Issue 中已定位到 api/services/trigger/trigger_subscription_builder_service.py 第 270 行，将 expires_at=subscription_builder.expires_at 改为 expires_at=subscription.expires_at）是否已包含在版本中，并升级到修复版本。

验证方法

执行上述临时方案后，等待下一次 trigger_subscription_refresh 任务（每分钟一次）运行，并在 worker 日志中确认出现了 Refresh subscription 或重新调用 Gmail watch 的相关记录。随后向该 Gmail 地址发送测试邮件，确认工作流触发器恢复触发，nginx 能收到 POST /triggers/plugin/<endpoint_id> 请求。若再次查询 trigger_subscriptions 表，expires_at 应更新为新的未来时间戳。