Disneyland Paris times returning error after some kind of hiccup

[dotaguro]

I'm still trying to track this down, but I've noticed that after a while of running fine, the two Disney Paris parks will start spitting out 504: {
"message": "Endpoint request timed out"
}.

Killing the task and restarting it restores it to working.

I think it's something to do with the API itself starting to reject the incoming requests... I ran the same code on two different machines in different data centers starting a few hours apart and both of them started to return the same error at approximately the same time (6:49 AM UTC) this morning (so each task was running for different amounts of time).

I'll see if I can get some more information next week (e.g. a more detailed stacktrace for which API call is being rejected, which I'm not currently logging), and dig through the code to see if some transient part of the URI or POST might be causing the rejections, but I figured I'd flag this now in case someone else knows the code off the top of their head and can suggest where to start.

[jeanmatthieud]

I have EXACTLY the same issue.
I though it was an issue on my end but I didn't find any way to avoid it.
I'm happy to see that I'm not alone lol

[DougSisk]

It looks like Disney has begun blocking IP addresses. I had to rotate mine out.

@cubehouse Is there an easy way with the Couchbase polling system to decrease the update interval to help avoid pissing off Disney?

[rraayy]

Due to the AWS was public their IP range, I think Disney's server(hosted by AkamaiGHost) is blocking these IPs. Few IP can run well on the AWS Lambda, every "save" will change the IP. You might find the working IP. (Maybe someday will be blocked?)
Google Cloud function also has the same behavior. T. T

[jeanmatthieud]

I don't think that it is the problem.
I personally own a fix IPv4. When it doesn't work anymore, I just have to restart my service and it is working again.

[dotaguro]

I agree with Jean-Matthieu; I can just kill and restart my fetcher and it works again. It seems like something's getting stuck.

…

On Tue, Feb 18, 2020 at 6:30 AM Jean-Matthieu DECHRISTÉ < ***@***.***> wrote: I don't think that it is the problem. I personally own a fix IPv4. When it doesn't work anymore, I just have to restart my service and it is working again. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#271?email_source=notifications&email_token=AAAVTOQBEDX2P75FTEP7T7LRDPWGTA5CNFSM4KLTBQ22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMCFQTA#issuecomment-587487308>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAVTOQTMGCGZWWEZTZTSTTRDPWGTANCNFSM4KLTBQ2Q> .

[cubehouse]

Only thing I can think to try is manually switching out the User Agent string every few hours, see if that stops this happening?
Something like this to generate a random Android UA string:

MyPark.UserAgent = (ua) {
  return (ua.osName === 'Android');
};

[jeanmatthieud]

I think that the issue is more recurrent when I'm calling the API when the park is closed.
I changed my code to only get the ride schedules 1h before / during / 1h after park opening hours, and the issue is less recurrent... maybe it's just a coincidence...