Facebook-chat-api: After a long while (~week) -- the API starts failing. Why???!?!?

Created on 15 Mar 2016 · 37Comments · Source: Schmavery/facebook-chat-api

ERR! Error in getUserInfo { error: 'JSON.parse error. Check the `detail` property on this error.',
ERR! Error in getUserInfo   detail: [SyntaxError: Unexpected token <],
ERR! Error in getUserInfo   res: '<html><head><title>Redirecting...</title><script>_script_path = "\\/4oh4.php";var uri_re=/^(?:(?:[^:\\/?#]+):)?(?:\\/\\/(?:[^\\/?#]*))?([^?#]*)(?:\\?([^#]*))?(?:#(.*))?/,target_domain=\'\';window.location.href.replace(uri_re,function(a,b,c,d){var e,f,g;e=f=b+(c?\'?\'+c:\'\');if(d){d=d.replace(/^(!|%21)/,\'\');g=d.charAt(0);if(g==\'/\'||g==\'\\\\\')e=d.replace(/^[\\\\\\/]+/,\'/\');}if(e!=f){if(window._script_path)document.cookie="rdir="+window._script_path+"; path=/; domain="+window.location.hostname.replace(/^.*(\\.facebook\\..*)$/i,\'$1\');window.location.replace(target_domain+e);}});</script><script type="text/javascript">/*<![CDATA[*/(function(){function si_cj(m){setTimeout(function(){new Image().src="https:\\/\\/error.facebook.com\\/common\\/scribe_endpoint.php?c=si_clickjacking&t=2329"+"&m="+m;},5000);}if(top!=self && !false){try{if(parent!=top){throw 1;}var si_cj_d=["apps.facebook.com","apps.beta.facebook.com"];var href=top.location.href.toLowerCase();for(var i=0;i<si_cj_d.length;i++){if (href.indexOf(si_cj_d[i])>=0){throw 1;}}si_cj("3 https:\\/\\/www.facebook.com\\/");}catch(e){si_cj("1 \\thttps:\\/\\/www.facebook.com\\/");window.document.write("\\u003Cstyle>body * {display:none !important;}\\u003C\\/style>\\u003Ca href=\\"#\\" onclick=\\"top.location.href=window.location.href\\" style=\\"display:block !important;padding:10px\\">Go to Facebook.com\\u003C\\/a>");/*J5lRKuPx*/}}}())/*]]>*/</script><script>window.location.replace("https:\\/\\/www.facebook.com\\/common\\/invalid_request.php?__req=5qb");</script><meta http-equiv="refresh" content="0;url=https://www.facebook.com/common/invalid_request.php?__req=5qb" /></head><body></body></html>' }

bug help wanted

Source

mehcode

Most helpful comment

Hey everyone, our bot marc has been up for about 2 weeks now and is still running!
I think we can close this for now as we've already secretly pushed to master our fixes ;)

I hope we'll never need to reopen this again. It's a slow process to test.

bsansouci on 10 Apr 2017

❤5 🎉5 👍5 😄4

All 37 comments

Does it fail consistently after it starts? Or do subsequent calls succeed? It may be some transient issue?

Schmavery on 15 Mar 2016

Does it fail consistently after it starts? Or do subsequent calls succeed? It may be some transient issue?

Fails continuously. I have to restart / reconnect for it to start working again.

mehcode on 15 Mar 2016

Do you have api.listen() running during this time, or do you just periodically send messages?

Schmavery on 15 Mar 2016

Do you have api.listen() running during this time, or do you just periodically send messages?

api.listen is running as well.

mehcode on 15 Mar 2016

@Schmavery I might be wrong but I think this is the problem we were having before. My best guess was that the cookies get invalidated. If this is the case, the fix is easy: query www.facebook.com every once in a while. If it's not, then it might be some edge case event that we're not responding correctly to.

bsansouci on 17 Mar 2016

Hopefully we can fix this so it stops coming back to haunt us #156 #168

Schmavery on 17 Mar 2016

Im not sure, but after long time of listening of pulls is sometime executed an ping GET request with some arguments (also named a sub, I think the PING is used too)

https://6-edge-chat.facebook.com/sub?cb=43gm&sticky_token=50&uid=100000203222282&viewer_uid=100000203222282&sticky_pool=lla1c14_chat-proxy&profile=desktop&clientid=7aba5403&cap=8&reset=t

gamelaster on 18 Mar 2016

Maybe the auto request of Facebook.com every 12-24 hours will be best solution. But for sample,I using too messenger.com really long (I not shut down the PC, I sleeping my PC) with active instance of chat, and I never get a "refresh" of site(but it will be reconnected). I Will take look to reconnect function. But anyway, Ping is only sometimes executed (not always, not in every refresh)

gamelaster on 18 Mar 2016

Not sure if this is duplicate but after a while, sending a message (within listen) seems to give:

{ error: 'JSON.parse error. Check the `detail` property on this error.',
  detail: [SyntaxError: Unexpected token <],
  res: '<html><head><title>Redirecting...</title><script>_script_path = "XChatUserInfoAsyncController";var uri_re=/^(?:(?:[^:\\/?#]+):)?(?:\\/\\/(?:[^\\/?#]*))?([^?#]*)(?:\\?([^#]*))?(?:#(.*))?/,target_domain=\'\';window.location.href.replace(uri_re,function(a,b,c,d){var e,f,g;e=f=b+(c?\'?\'+c:\'\');if(d){d=d.replace(/^(!|%21)/,\'\');g=d.charAt(0);if(g==\'/\'||g==\'\\\\\')e=d.replace(/^[\\\\\\/]+/,\'/\');}if(e!=f){if(window._script_path)document.cookie="rdir="+window._script_path+"; path=/; domain="+window.location.hostname.replace(/^.*(\\.facebook\\..*)$/i,\'$1\');window.location.replace(target_domain+e);}});</script><script type="text/javascript">/*<![CDATA[*/(function(){function si_cj(m){setTimeout(function(){new Image().src="https:\\/\\/error.facebook.com\\/common\\/scribe_endpoint.php?c=si_clickjacking&t=9154"+"&m="+m;},5000);}if(top!=self && !false){try{if(parent!=top){throw 1;}var si_cj_d=["apps.facebook.com","apps.beta.facebook.com"];var href=top.location.href.toLowerCase();for(var i=0;i<si_cj_d.length;i++){if (href.indexOf(si_cj_d[i])>=0){throw 1;}}si_cj("3 https:\\/\\/www.facebook.com\\/");}catch(e){si_cj("1 \\thttps:\\/\\/www.facebook.com\\/");window.document.write("\\u003Cstyle>body * {display:none !important;}\\u003C\\/style>\\u003Ca href=\\"#\\" onclick=\\"top.location.href=window.location.href\\" style=\\"display:block !important;padding:10px\\">Go to Facebook.com\\u003C\\/a>");/*JrlLT6n_*/}}}())/*]]>*/</script><script>window.location.replace("https:\\/\\/www.facebook.com\\/common\\/invalid_request.php?__req=2f");</script><meta http-equiv="refresh" content="0;url=https://www.facebook.com/common/invalid_request.php?__req=2f" /></head><body></body></html>' }

louisrli on 6 May 2016

This seems to be the same issue yeah... We're not 100% sure but think making a request to FB every once in a while to tell it that you're alive seems like it would work.

bsansouci on 6 May 2016

Yeah.. I guess in this case you aren't running the listen function?

Schmavery on 7 May 2016

Nope, this is within the listen function callback.

On Sat, May 7, 2016, 9:03 AM Avery Morin [email protected] wrote:

Yeah.. I guess in this case you aren't running the listen function?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/Schmavery/facebook-chat-api/issues/202#issuecomment-217633833

louisrli on 7 May 2016

Same problem here :(

cookkkie on 26 Jul 2016

I have a similar problem. After few day, sometimes even less than one day, my listen function no longer work. Orz

ALiangLiang on 31 Jul 2016

IMHO we should define a workaround to this problem and include it in the readme. Is scheduled pinging a random facebook page a solid workaround?

krokofant on 12 Oct 2016

@krokofant sorry about this issue. I think a very easy workaround is to silently kill and restart. Saving the cookies first to some string, then stop listening and re-login with the cookies. That should be enough to make their servers think the user refreshed the page and should be very fast. If you want to be correct you'll have to make sure you didn't miss any messages in that small window of time.

bsansouci on 12 Oct 2016

I am sorry if duplicate, is there any solution for this sending message error?

ERR! Error in getUserInfo { error: 'JSON.parse error. Check the detail property on this error.',
ERR! Error in getUserInfo detail: [SyntaxError: Unexpected token <],
ERR! Error in getUserInfo res: 'Redirecting...' }

nanangsujoko on 3 Nov 2016

I'm currently working around it by restarting my app every night which is horrible but seems to work. Would be great if the library could take care of this with some kind of "keep alive" mechanism as hacking at the container layer is pretty nasty.

jkp on 15 Jan 2017

Hey @jkp, totally agree, unfortunately neither me nor @bsansouci has had time in our schedules to do it. If someone submitted a PR to fix this, we'd offer many emoji hearts and clicking of merge buttons in return.
We've been trying to figure out which url to ping in listen in order to stay alive but not much success yet.

Schmavery on 16 Jan 2017

😄3

Hi! I've had messenger open for about 23 hours now..

GET
https://2-edge-chat.messenger.com/pull?channel=p_...&seq=122&partition=-2&clientid=...&cb=lmn8&idle=49029&qp=y&cap=8&pws=fresh&isq=42&msgs_recv=122&uid=...&viewer_uid=...&sticky_token=31&sticky_pool=ash2c06_chat-proxy&mode=stream&format=json
Every 50 seconds

POST
https://www.messenger.com/rtc/callability/?user_id=...&dpr=1
Every 450 seconds

and POST to
https://www.messenger.com/ajax/bz
Every 60 seconds

featherbear on 6 Feb 2017

I've done something similar to what @jkp has done but using pm2 as a process manager and I'm telling the process to restart itself every 24 hours. The process detects a restart and saves it's state which it restores on startup.

setTimeout(() => {
  console.info('Restarting')
  pm2.connect((err) => {
    if (err) console.error('Could not connect to pm2: ', err)
    pm2.restart(
      require('./ecosystem.config.js').apps[0].name, // app name in pm2
      (err) => {
        console.error('Could not init restart: ', err)
      })
  })
}, 1000 * 3600 * 24)

Saving state

process.on('SIGINT', () => {
      console.log('Shutting down bot')
      jsonfile.writeFileSync(statefile, this.api.getAppState())
      process.exit()
    })

Handle login

let loginCallback = (err, api) => {
      if (err) {
        console.error('Login failed. Bot instance invalid.')
        throw err
      }
      this.api = api
      this.handleEvents()
    }

    let state = fs.existsSync(statefile) ? jsonfile.readFileSync(statefile, {throws: false}) : null

    if (state) {
      login({appState: state}, loginCallback)
    } else {
      login({
        email: username,
        password
      }, loginCallback)
    }

krokofant on 6 Feb 2017

Well yes, but I would much rather get the bug fixed than to make a workaround you know :)

featherbear on 6 Feb 2017

@bearbear12345 My comment wasn't really a response to your comment. I just thought I'd share my workaround implementation.

It seems unclear to me what you mean by your comment, are the requests you specified a solution to this issue?

krokofant on 6 Feb 2017

Haha yeah that's fine.. just was continuing what @GAMELASTER and @bsansouci proposed earlier

featherbear on 6 Feb 2017

@bearbear12345 Please do report back if that solution is viable for a ~week uptime 🍪

krokofant on 6 Feb 2017

👍1

@bearbear12345 For what it's worth, we actually make most of our calls to facebook.com rather than messenger.com. Maybe this should be changed but so far it's seemed ok.

Afaik, we already make the call to edge-chat.facebook.com/pull (we always make it to 0-edge-chat). This should be running as long as you have a listen in your code.
I don't think we make the other two calls. Hard to know if they're related. So far I'd treated them as unneeded because the api fails after several days, not several minutes/hours. Who knows. It's definitely worth trying them if they're our only option. The main reason we never tried to do the ajax/bz call is that it seems to carry a non-trivial json blob that would (probably?) have to be reproduced.

Schmavery on 6 Feb 2017

The main reason we never tried to do the ajax/bz call is that it seems to carry a non-trivial json blob that would (probably?) have to be reproduced.

/ajax/bz is just a generic endpoint for event logging, it shouldn't affect the session at all.

Daniel15 on 2 Mar 2017

@Daniel15 Haha thanks for the info! We had kinda guessed it would be as we ignored those and everything worked as intended. As a side note, we trimmed down the requests by doing some trial/error until we had the minimum number of params to make things work. So I think we're skipping a lot of logging things.

Some progress for you all: it seems like FB is sending cookies not in the HTTP header (as is normally done) but as part of the response to listen!
We already knew that but now there's a new thing that we didn't know changed over time: dtsg.

It looks like:

{
  jsmods: {
    require: [
      ["DTSG", "setToken", "", ["new token is here"]],
    ]
  }
}

It seems like after ~3 days, FB starts sending that as part of the response. Looking at their code, when they make a new request they use the latest one they've received. I've been running an experiment for 2 weeks and it _seems_ like this solves this issue. I was able to have our bot running for more than 3 days (which was its limit before starting to die) up to 5 days or something like that. I ran into another issue because of a typo which ruined the experiment, so I'm running it again.

Another issue is that we sometimes get EAI_AGAIN when a request to https://0-edge-chat.facebook.com/pull. Yes we hardcoded 0 (sorry FB, no load balancing for you). EAI_AGAIN seems to mean, I quote, "EAI_AGAIN is actually a DNS lookup timed out error means it is either a network connectivity error or some proxy related error". So now we simply say fuck it and we swap servers random between 0 and 6 :)
That has helped a bit too I think...

Now we wait...

¯\_(ツ)_/¯

bsansouci on 1 Apr 2017

😄3

it seems like FB is sending cookies not in the HTTP header (as is normally done) but as part of the response to listen

It's not a cookie, it's a JS method call on Facebook. It's essentially calling require('DTSG').setToken. :)

Daniel15 on 1 Apr 2017

@Daniel15 Oh right sorry that is what I meant.
Also I get confused by a line in a module called getAsyncParams which is var e = require("DTSG").getCachedToken ? require("DTSG").getCachedToken() : require("DTSG").getToken();
When I grep-ed the codebase it seemed like getCachedToken didn't exist...

bsansouci on 2 Apr 2017

👍1

Hey everyone, our bot marc has been up for about 2 weeks now and is still running!
I think we can close this for now as we've already secretly pushed to master our fixes ;)

I hope we'll never need to reopen this again. It's a slow process to test.

bsansouci on 10 Apr 2017

❤5 🎉5 👍5 😄4

Hmm I think the problem resurfaced again, as my bot keeps throwing errors after running for more than 2 (or 3?) days. I tried logging out and re-logging in again, but realized the current appstate.json would become invalid after logout. Perhaps Facebook made some changes again? 😭

kentnek on 14 Apr 2018

👍1

I'm also getting the same behavior. Error message:
Unhandled rejection Error: parseAndCheckLogin got status code: 400

MathTauAthogen on 19 Sep 2018

@MathTauAthogen Even though I get these errors, my script seems to still run fine - Is your error a breaking error?

featherbear on 19 Sep 2018

Yes. My code consists of a single api.listen call, and it seems to stops listening after the error, or at the very least calls to api.deleteMessage seem to fail. However, that does not crash the code, which means that using forever.js doesn't re-run it.

MathTauAthogen on 19 Sep 2018

I guess you could forcibly make the script exit when it encounters the error, so forever.js gets triggered

featherbear on 20 Sep 2018

hi guys
I'm also getting the same behavior. Error message:
Unhandled rejection Error: parseAndCheckLogin got status code: 400
How to cancel log error on command when see that error
thanks & hope help