No, the error i get is for the url `https://api.twitter.com/1.1/onboarding/sso_init.json` and the error is "Over capacity" code 130. The client keeps looping on this call too so idk if the load will ever dissipate lol.
It doesn't seem to include any backoff, so any browser tab left open on that screen will keep tightlooping on it. Almost certainly exacerbating the problem.
What should my mental model be for "where" the code that causes those repetitive API requests is coming from? JS logic deployed to a CDN somewhere?
If so, seems it may be an interesting question of whether or not it's possible to ship a hotfix (add exponential backoff) to JS asset in time to be helpful in fighting an outage like this.
> Honestly pretty shocked that something at their scale could be depending on Fastly for core assets.
Why would that be surprising? Fastly has many customers of similar scale. Amazon.com has fastly as one of the options to serve as their CDN (as was publicized when a fastly outage took down amazon briefly last year).
Probably reductive but in my head Cloudlfare and Cloudfront are the only 2 "mega large" CDNs and, to your point, I've only ever heard about Fastly in the context of outages.
What should my mental model be for "where" the code that causes those repetitive API requests is coming from? JS logic deployed to a CDN somewhere?
If so, seems it may be an interesting question of whether or not it's possible to ship a hotfix (add exponential backoff) to JS asset in time to be helpful in fighting an outage like this.