This is my code
var stop = api.listen(function(err, message){
if(err) return console.error(err);
console.log(message.body);
if(req === '/stop'){
return stop();
}
});
When I send message to my account, It doesn't listen my message and console.log(message.body).
But it ran well yesterday.
I'm having the same issue
Same here. Let me add some information about the issue:
api.setOptions({listenEvents: true}) and events (read, typ, video-call lost) are captured. Nothing for messages, stickers, uploads...It is probably due to changes in Facebook. _(Sorry my English =)_
Thanks for letting us know. I just tried to do some investigation here and my test account seems to be having trouble receiving messages in the browser... Not sure what the problem could be, will try again later. Please comment if anyone discovers anything relevant. Listen seems to still work for pages, when I test it.
Okay, I think I've managed to figure out the reason it's not working... looks like facebook is trying out an entirely new format of sending messages using an event type called "delta".
This is a single-user chat:

This is a group chat:

They may have modified other events too...

I think I should be able to get a quick fix working pretty soon, but as you might have noticed, this new event doesn't have nearly as much information as the old one, so we are looking at potentially having to deprecate the old message object signature.
Hey everyone, can you try updating to master and testing commit 7fe18c4? All of the tests are passing again now.
It's a bit of a temporary fix, but it should restore major functionality for now.
@Schmavery
works nice (tested group and normal user too)
@Schmavery Doesn't work for me, gives such a weird behaviour. Sometimes nothing happens, sometimes it triggers the callback but message.body is undefined (this seems to happen when the message starts with a slash)
@ErmanSayin
That its interesting, for me its working long time good, without any problem, + now its responses really faster than before, almost after a sent of message I got response from my bot, so...
@Schmavery For me it calls the callback twice, which it didn't do until recently
After some testing: here's what happens for me;
Callback doesn't trigger when a message is sent to single-chat from someone else;
Error when a message is sent to a group chat from someone else:
ERR! ERROR in listen --> TypeError: Cannot read property 'map' of undefined
ERR! ERROR in listen --> at Object.formatDeltaMessage (/root/fb-bot/node_modules/facebook-chat-api/utils.js:357:35)
ERR! ERROR in listen --> at parsePackets (/root/fb-bot/node_modules/facebook-chat-api/src/listen.js:155:34)
ERR! ERROR in listen --> at Array.forEach (native)
ERR! ERROR in listen --> at /root/fb-bot/node_modules/facebook-chat-api/src/listen.js:108:12
ERR! ERROR in listen --> at tryCatcher (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/util.js:26:23)
ERR! ERROR in listen --> at Promise._settlePromiseFromHandler (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/promise.js:507:31)
ERR! ERROR in listen --> at Promise._settlePromiseAt (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/promise.js:581:18)
ERR! ERROR in listen --> at Promise._settlePromises (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/promise.js:697:14)
ERR! ERROR in listen --> at Async._drainQueue (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/async.js:123:16)
ERR! ERROR in listen --> at Async._drainQueues (/root/fb-bot/node_modules/facebook-chat-api/node_modules/bluebird/js/main/async.js:133:10)
ERR! ERROR in listen --> at Immediate.Async.drainQueues as _onImmediate
ERR! ERROR in listen --> at processImmediate as _immediateCallback
ERR! ERROR in listen --> [TypeError: Cannot read property 'map' of undefined]
@ErmanSayin You can make a quick fix here by changing that exact line to exactly attachments: (delta.attachments || []).map(v => _formatAttachment(v.mercury)),
@bsansouci That seems to have fixed the error, but the callback still isn't getting triggered whenever there's a message sent
@TexAgg had you been experiencing the initial issue of listen not working?
@Schmavery no it works fine
Ok so what must have happened is that they have enabled the delta events for everyone but only some accounts are using them so far. Not sure how to detect the difference, so I might have to add a global option to turn on delta events.
@TexAgg if you want to disable the extra messages quickly for now, you can make a quick fix by putting a return; statement right after the delta case, here. This will disable the new event.
@Schmavery Do you have any ETA of a npm release? I use your fantastic module for a bot, and don't really want to use temporary fix by editing some files in node_modules...
@Mavyre which fix are you talking about here? You can always sync to master using npm if you don't want to edit files manually. If you're talking about the fix that adds delta events, what we have here is still a pretty rough fix... I want to come up with some plan of action for the signature change before releasing to npm...
That said, this is pretty core functionality, so I'm hoping to clean it up within the next couple of days.
if you were talking about @TexAgg's fix, I'm away from a computer right now so I can't make the change to add a switch to turn delta events off.
@TexAgg I added disableDelta to the options (use api.setOptions() etc) that you can set to true. This will also autotrigger if you receive any of the old kind of message. Hopefully this works for now.
omfg, somewhere in my code I had console.log set to an empty function, so I thought the log functions weren't triggering because the callback didn't work. :sob:
Anyway, for some reason message.senderName is null for me. Am I meant to use an extra function to retrieve the name?
Here's a temporary fix for ya:
api.getUserInfo([message.senderID], function(err, obj){
message.senderName = obj[message.senderID].name;// stuff
});
Recommend caching it, because it quite slows it down
@ErmanSayin senderName missing is a known issue #197 #219
Help got this error if I put deltaDisable
`/root/olaf-bot/server.js:76
disableDelta: true
^^^^^^^^^^^^
SyntaxError: Unexpected identifier
at exports.runInThisContext (vm.js:53:16)
at Module._compile (module.js:387:25)
at Object.Module._extensions..js (module.js:422:10)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Function.Module.runMain (module.js:447:10)
at startup (node.js:141:18)
at node.js:933:3
`
I put it in my code here
function callback(err, api) {
if (err) return console.error(err);
api.setOptions({
listenEvents: true
disableDelta: true
});
I am attentive to your prompt response @Schmavery
@Theblood you forgot the comma between the two properties
@ErmanSayin thank you very much I had not realized the mistake he had but now in the log out another mistake if I can help ?
WARN Unrecognized option given to setOptions disableDelta
You need to update the package from master.
cd node_modules
rm -rf facebook-chat-api
鈥媑it clone http://github.com/Schmavery/facebook-chat-api.git
cd 鈥媐acebook-chat-api
npm update
Many estimates are very great thanks you _-_ ! , Thank you very much to you especially @ErmanSayin
Here is the code for those coming for the problem:
api.setOptions({
listenEvents: true,
disableDelta: false
});
Isn't this what I said...?
Thanks for helping, ErmanSayin
It stopped working for me, I updated to the newest version, the account is online but there is no events in the log...
@julianengel when you say the latest version, do you mean on npm? This fix is only in master right now.
@Schmavery No, from github. It was working yesterday after npm stopped, but now it stopped too....
@julianengel hard to imagine them changing the system twice within a couple days.. Not sure what's happening there. The tests are still working for me. Can you try adding a log after case 'delta': here at line 151 saying console.log(ctx.globalOptions.disableDelta, v.delta.class, v) or something similar so that we can see if you're getting delta events at all.
@Schmavery What I wanted to say thank you all for your great help
@Schmavery @julianengel the delta is working excellent repair, you can follow the instructions that are on the same thread to implement the disableDelta @ErmanSayin
I dont know why but my app (yea listen) still works on latest git version without setting disableDelta via settings (in group its working too)
Downloaded GIT master
cd to repo npm update
Problem:
I am having 2 result i only sent the message once but i am receiving it twice.
CODE
var login = require("facebook-chat-api-master");
// Create simple echo bot
login({email: "myusername", password: "mypassword"}, function callback (err, api) {
if(err) return console.error(err);
console.log('success');
api.listen(function callback(err, message) {
console.log('++++++++++++++++++++');
console.log(message.body);
console.log(message.senderID);
console.log('++++++++++++++++++++');
console.log(' ');
process.title = "TESTING";
// api.sendMessage(message.body, message.threadID);
});
});`
RESULTS
++++++++++++++++++++
dolce amor
0000000000000000
++++++++++++++++++++
++++++++++++++++++++
dolce amor
0000000000000000
++++++++++++++++++++`
Update:
happens only when
api.setOptions({ disableDelta: false });
@tomexsans can you try to add an condition if message.type == "message"?
@GAMELASTER it does not solve the error. Note that when disableDelta is set to false when you log a message obj it will return two objects of message.type == message.
@tomexsans That it's interesting, I running on latest without setting disableDelta = false and all works good (yet) (but I don't know if default of disableDelta is true or false, so I don't know if I'm running on delta or not). Maybe I still got old format of messenger because i'm from Slovakia, where updates for Facebook going reaaaally slow! (but I think when I last time checking the poll request from FB it's has been a Delta)
@GAMELASTER we set disableDelta to false by default because some people hit the new FB API and therefore need to be able to use this API by default. The reason we added this flag was for people who had this weird in-between where FB would send both type of messages. Those people can set disableDelta to true and their problems will be solved.
I'm hoping to be able to be able to implement the long-term fixes for this issue this weekend, so that all this confusion can be behind us.
DisableDelta will turn itself on automatically after the first message if your client is still receiving the old type of message. The worst that should be able to happen is for you to receive 2 of the first message, and then you shouldn't get duplicates after that. If this bothers you, and you know you're still getting the old type of message, set disableDelta to true manually.
Yes, I have disabledDelta = true automatically, so as I said upper, its because my country getting an updates really slow, if I will set the locale to America, I will get an Delta data. So for this all working good for me.
Hey everyone,
I have pushed beae8ba16ad55f7bc1a763a4274989a8e6dee3f4, which officially turns off the old style of messages. Please refer to #219 or the docs for the new signature. As a result, disableDelta is no longer needed.
I feel like this issue is now resolved. If you have any problem specifically with this issue, feel free to comment here. Otherwise, design concerns should be addressed in #219.
Most helpful comment
I think I should be able to get a quick fix working pretty soon, but as you might have noticed, this new event doesn't have nearly as much information as the old one, so we are looking at potentially having to deprecate the old message object signature.