移交协议未传递线程所有权-但它带来了“成功”响应-似乎是错误

Posted 2023-03-17

【中文标题】移交协议未传递线程所有权-但它带来了“成功”响应-似乎是错误

【英文标题】：Handover Protocol not passing thread ownership - But it brings "success" response - seems like Bug

【发布时间】：2019-01-02 07:14:57

【问题描述】：

我正在尝试为我的 Messenger 机器人实施 Messenger 移交协议，但 Pass_Thread_Control 并未将所有权从主要接收方移交给次要接收方（收件箱）。

在打开这个帖子之前，我已经尝试了 100 多次不同的组合。当用户点击“传递到收件箱”快速回复时，机器人（与 Python 集成的 Dialogflow）启动 Webhook 并执行以下操作：

获取 Facebook 页面 - 次要接收者（收件箱）ID 和线程所有者响应（通常主要接收者 [FB 应用程序] 是线程所有者） 使用正确的输入 "success":true 执行 Graph API Pass_Thread_Control 再次调用Graph API Thread Owner，发现Primary Receiver仍然是线程所有者（而应该是Secondary Receiver，应该是线程所有者）

因此，用户消息不会自动从 Facebook 页面“完成”文件夹转移到“收件箱”。

其他配置： [1] FB Page 已订阅 FB App [2] 为 FB 页面选择的事件：messaging、messaging_postbacks、messaging_handovers、standby、messaging_policy_enforcement [3] FB Page --> Primary Receiver: FB APP, Secondary Receiver: Page Inbox

def human_control(req):

# GET ID OF INCOMING USER FROM WEBHOOK
id=req.get('originalDetectIntentRequest').get('payload').get('data').get('sender').get('id')

# CURRENT THREAD OWNER (BEFORE PASS_THREAD_CONTROL RUNS)

current_thread_owner = "https://graph.facebook.com/v2.6/me/thread_owner?recipient=" + id + "&access_token=" + ACCESS_TOKEN
result = urllib.request.urlopen(current_thread_owner).read()

# PASS_THREAD_CONTROL JSON Parameters:

target_payload = 
   "recipient": "id": id,
   "target_app_id": "263902037430900",
   "metadata": req.get('queryResult').get('queryText') 
   

# PASS_THREAD_CONTROL - To Secondary Inbox - via Graph API call
# BELOW FORMAT WORKS ONLY IN PYTHON & BRINGS SUCCESS
# FB SUGGESTED WAY: https://developers.facebook.com/docs/messenger-platform/handover-protocol/pass-thread-control

pass_control_result = requests.post("https://graph.facebook.com/v2.6/" + id + "?pass_thread_control&access_token=" + ACCESS_TOKEN, params=target_payload)

# CURRENT THREAD OWNER (BEFORE PASS_THREAD_CONTROL RUNS)

current_thread_owner = "https://graph.facebook.com/v2.6/me/thread_owner?recipient=" + id + "&access_token=" + ACCESS_TOKEN
result = urllib.request.urlopen(current_thread_owner).read()

res =  
    "payload": 
        "facebook": 
           "text": "Wait a while. Our Admin will be in touch shortly.",
           "quick_replies": [
             
              "content_type": "text",
              "title": "Back to Bot",
              "payload": "Back to Bot",
             
          ]
       
   ,
 ;
res = json.dumps(res, indent=4)
print (res)
r = make_response(res)
r.headers['Content-Type'] = 'application/json'
return r 

预期结果-->

当前线程所有者（通过线程调用之前）-> 214020109069642（FB 应用程序是主要接收者）----> 'data': ['thread_owner': 'app_id': '214020109069642']

通过线程控制---> "success":true

再次成为当前线程所有者 ---> 263902037430900（FB 页面收件箱 ID）。次要接收者应接替主要接收者的角色

传递线程控制 JSON 有效负载应存在于 Webhook 响应中

实际结果 -->

当前线程所有者（通过线程调用之前）-> 214020109069642（FB 应用程序是主要接收者） 'data': ['thread_owner': 'app_id': '214020109069642']---->正确

通过线程控制 ---> "success":true--> 正确

再次成为当前线程所有者 ---> 214020109069642（FB 应用程序 ID）####After 运行通过线程控制 API，辅助接收器 ID：263902037430900 | NAME: 页面收件箱 --> 错误

传递线程控制 JSON 有效负载应该存在于 Webhook 响应中 --> 不来

【问题讨论】：

这对我来说很好用。您可能希望确保为您的调用使用当前的 API 版本（v2.6 已被弃用），但这可能不是您的实际问题的原因。除了确定当前线程所有者的调用之外，将线程控制传递给收件箱本身是否有效？将线程控制传递给收件箱后，您是否在收件箱文件夹中看到对话？

感谢拉斯的评论。我刚刚尝试使用 v3.2（之前也尝试过），但没有成功。结果和以前一样。我不知道我会怎么做。有效载荷也不是来自信使响应，这也很奇怪。 "pass_thread_control": "new_owner_app_id":"123456789", "metadata":"调用者要设置的附加内容"

【参考方案1】：

我想我已经解决了这个问题。这不是错误。而是没有在此处传递参数（标头），从而导致此处出现错误的响应。对于这样一个愚蠢的错误，我很抱歉（并为此浪费了 3 天时间）。下面是正确的语法：

headers = 'Content-type': 'application/json'

target_payload = 
"recipient": "id": id,
"target_app_id": target_inbox_id ,
"metadata": req.get('queryResult').get('queryText')


pass_control_result = requests.post("https://graph.facebook.com/v3.2/me/pass_thread_control?access_token=" + ACCESS_TOKEN, data=json.dumps(target_payload), headers=headers)

只有一个查询： 一旦机器人待命（人类与收件箱中的用户交谈），它不会响应聊天命令来控制线程（例如：如果用户单击“返回机器人”按钮，机器人在待机模式下保持沉默且没有 webhook进一步生成响应）。

只有“标记为完成”点击才能再次启用机器人。 用户有什么方法可以再次通过机器人调用线程控制（无需管理员点击“标记为完成”）？由于它没有响应任何命令，调用“Request Thread Owner”或“Take Thread Control”API 也不起作用。