all.
On the last week we are facing a problem in messages order, in Facebook Messenger.
When user is interacting with our bot, on most of the cases Messenger send random messages that it has sent before in the conversation. This old messages are not triggered by our bot, they simply appear, which makes us to think it is a Messenger thing. After a while, when user leave the conversation for some seconds and get back to it later, the bot is ok again. Sometimes user has to say "hi" to bot, so it gets back to the right point of conversation.
It also happens with messages that were sent by user, not only by our bot.
We have never get this problem using it on web platform. It seems to occur only in Android devices (Android massenger app), until this point.
When we check the conversation from the fan page side, it is all ok, and it is hard to determine where the problem occured just by looking from the fan page perspective. It seems there is no problem. But if you are the one who is interacting with the bot is very bad, it is like a "crazy" conversation for the end user.
It is a different case from the listed on other topics. We have an information thread that sends lots of messages, and in this case for example, it has never failed in order. It just happens when there is an user-bot interaction.
Is anybody here facing this kind of problem with messages order?
Thank you in advance.
we have seen the same behavior in android
On further investigation, we found that the messages which we assumed are delivered to the users were actually not delivered.
What we did was started listening to delivery notification and read receipts documentation link. We saved every message at our end and then mapped with seq number and it turns out that there is connectivity issues in android for fb messenger (reference).
When fb messenger is running in background and there is poor network connection then messages are not being received. This is what I have observed when I have poor network connection.
Related
I can see from this, that a bot can send a message in chat, and if supplied a thread ID that does not exist, will start a new thread and post there. I am wondering if there is a way, given the current REST API or any other compatible with Hangouts, to send a message to a room at a given time of day, rather than when the bot is called or interacted with.
I am working in NodeJS, deploying my project in the GCP.
My apologies for the ambiguity of my question, I am trying to wrap my mind around the GCP environment.
In the bots documentation there are described the three ways in which a bot can send a message to a room. Those are:
Every time the bot is mentioned.
When the bot enters a room for the first time.
When the bot is taken out of the room.
Unfortunately, none of them is a daily message at a given time. If you still have questions, please ask them freely.
We have a working bot (NodeJS based) which sends messages freely. Just use this endpoint https://developers.google.com/hangouts/chat/reference/rest/v1/spaces.messages/create .
Your bot must be invited to the particular space/room for this. You can create threads as well with new and subsequent messages.
We also have bots written in Google Apps Script and there it is also possible.
I'm testing a facebook instant games app and want my bot to collect messaging_game_plays events to log user data at the end of a play session.
I've set up an app page, app, and uploaded a build that I have moved to the testing stage. I also have a bot with a public webhook that I have successfully verified. The webhook is currently subscribed to messaging_game_plays as well as messages. I have simple echo functionality built into the bot and can spin up the messenger app on my phone, message the page, and receive an echo perfectly.
The problem arises when I go to the games section of my messenger app, play the game, and then exit the game. I expect my bot to receive a messaging_game_plays event per https://developers.facebook.com/docs/messenger-platform/reference/webhook-events/messaging_game_plays/, but I don't receive any indication in the logs of the bot server that anything has called the webhook (even after waiting a significant amount of time).
So my question is/questions are: am I missing something that is required for the messaging_game_plays to be sent to my bot? Is there anything that I need to add to my app-build specifically for this event to trigger? Is launching the game on my phone and exiting the game sufficient for testing this event?
I've searched forums and documentation with no luck but maybe I've missed something along the way. I have checked this question: Facebook Messenger webhook setup, but not triggered, and that helped me successfully trigger messages events which I am getting, I just can't seem to collect messaging_game_plays events.
I am rather new to this process so I may be missing something small, any help would be greatly appreciated!
For reference:
app webhook subscriptions
What does your fbapp-config.json file say? If your bot opt-in parameter is 'opt_in_dev' or 'opt_in_public' you will need to call the subscribeBotAsync method to subscribe your user to the bot before any webhooks will be sent.
Messenger bots will need to be opt-in only from January 19th (see here: https://www.facebook.com/fbgaminghome/blog/important-game-bots-update).
We're making this change to ensure a better player experience.
If you want to transfer player data without requiring the bot to be opted-in, you can use standard JavaScript fetch/XMLHttpRequest with getSignedPlayerInfoAsync to avoid tampering.
I have written a Facebook bot that is working well. The app is subscribed to my page and I am getting/sending messages/postbacks just fine. Woo!
Here's the downside - now that we have hundreds of users using the bot, the page "inbox" has become a nightmare.
We still have users that send normal messages to the page, and the bot knows not to respond. However, it's difficult to find those messages as we will have hundreds of unread "messages" or "threads" in the page inbox.
I tried to find a way to mark the items as read after the bot processes them.
The bot has the rights to read all messages for the page, as it sees the non-subscribed messages come in.
I tried using sender_action => mark_seen (which shows the user that the bot has seen the message, but unfortunately does not mark it as read in the inbox). Even when the bot sends the last message (which is normal), it still shows that the thread is unread.
Thanks!
I'm working with Facebook pages and building an app that allows you to send/receive private messages for your page from an external app.
Everything works fine, I can import old messages, send new one. My issue comes from the real time update subscription.
As explained here and here, I have subscribed to the conversations field on the page object. I also set up my server to receive Facebook verification and the updates.
I do receive updates when someone sends a new message to my test page ( even if it's a bit slow ~30 sec delay ) but I never receive any updates when the page replies to a message.
Is there something else I need to subscribe to in order to receive these updates ? Do I need to look for another way to do it ? Or is it just not supported by Facebook real time API updates ?
Any help appreciated, let me know if you need more info and have a nice day.
Currently im trouble shooting some code that I wrote to create a chat room. I will include the code if necessary but for now I just wanted to hear some possibilities for the problem im having. So basically I have client1 that is listening to a channel and then when clien2 sends a message to the server the message is then sent from the server to all available users. What is happening is that client 2 will send the message and it will be displayed on his browser but client 1 will not receive the message until he refreshes the page or types in a message of his own. So I would think that user presence is being detected fine since the message eventually gets sent to all available users but im not sure? Thoughts?
The Google App Engine blog has a nice case study that talks about how to do this.
They store a list of channel ID's in memcache and send update messages to each of them. They mention that race conditions make memcache not ideal, but it worked well enough for their demo.