简体   繁体   中英

Facebook Messenger Webhook continuously sending messages

I am learning to work with Facebook Messenger API. I have successfully setup a webhook, I have subscribe to the application. But when I send message to my Page I receive multiple instances of the same message like a burst.

I am storing messages which I send from my application when it is receive at the Webhook.

A view of my database look like in the screenshot below.

http://prntscr.com/au3emz

I am guessing it may be because the message is still unread? Just a wild guess may be someone else know for sure. I tried exact example of the Facebook Office (Node) and it is happening there as well.

Thanks.

This is often caused if you subscribe to the echo message callback event .

From the documentation;

This callback will occur when a message has been sent by your page.

What this implies is that you will get back a copy of any message your bot sends. From your code, this will cause a form of infinite loop; you would keep receiving Response 1 .

You can easily confirm this by inspecting the value of text ; you'll find it's also Response 1 and on inspecting the entire payload it will have the field "is_echo":true .

Solution: Edit your page subscription to exclude message_echoes

在此输入图像描述

When someone send a message to your Facebook Page, Facebook transfer that message to your Webhook address and waits for a http response like OK. And it keeps sending the same message to your webhook until the response arrives.

From Facebook webhook docs ( Webhook docs ;

Required 200 OK Response When you receive a webhook event, you must always return a 200 OK HTTP response. The Messenger Platform will resend the webhook event every 20 seconds, until a 200 OK response is received. Failing to return a 200 OK may cause your webhook to be unsubscribed by the Messenger Platform.

A delivery receipt will automatically be sent to the user after your webhook has acknowledged the message. You can also use Sender Actions to notify that the message has been seen.

You can see that all of those messages have the same timestamp.

As a solution; you can define a message queue to store those messages, and you add message to the queue if there is no such message in queue with the message sender id and timestamp.

Hope this helps,

I had the same issue with my test application. I am still new to Messenger API and my solution may be naive.

Initially, the code was like:

if (text) {
  sendTextMessage(sender, 'Response 1');
} else {
  queryDB(
    sendTextMessage(sender, 'Response 2');
  )
}
res.sendStatus(200);

Which kept sending Response 1 forever. The correct code is:

if (text) {
  sendTextMessage(sender, 'Response 1');
  res.sendStatus(200);
} else {
  queryDB(
    sendTextMessage(sender, 'Response 2');
    res.sendStatus(200);
  )
}

You have to sendStatus always after sending a message.

I detect that betwen facebook invocation and my response with 200 statuscode my code was waiting 2 seconds, my code is syncronous, thus , my total code responds with 200 code 2 seconds after..
Many probes results for me that if i dont send 200 status code to facebook in one second facebook resend message to webhook. For me the aolution was analyze the incoming message and obtain the timestamp key (A), then i get a timestamp.from a database (B). compare A==B.. if is true, i do nothig and ends.my webhook processing, if is false then write in the database the new timestamp (A) and continue with webhook proceasing.

Solution

I sent a subscription request again to my application to stop these messages.

So essentially what I experienced is that webhook re-subscribe app after having received message will stop any further receives until next message.

This is although the solution the core of "Why this happens?" is not known yet. Will be glad if someone can contribute.

Thanks.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM