3 ms·

What I don't understand here is, how did this break apps that had "old" SDK versions? Did some HTTP call the initialization code make end up raising an excepti

What I don't understand here is, how did this break apps that had "old" SDK versions? Did some HTTP call the initialization code make end up raising an exception on some unexpected status code and end up crashing the entire application? I don't understand why this kind of control flow is acceptable. Is it documented at least? And if it is documented, how come we can't fork this SDK (seems to be on GitHub, seems fork-eable) and remove this "feature"?

justinclift 6y ago
Although it's speculation, the observed behaviour matches what would happen if some depended-upon HTTPS certificate expired or was revoked. eg the mass Digicert EV cert revocation on Saturday
geofft 6y ago
The backtrace in https://github.com/facebook/facebook-ios-sdk/issues/1374 https://github.com/facebook/facebook-ios-sdk/issues/1374 makes it sound like they passed a nil pointer to NSOrderedSet's initWithSet method, from inside FBSDKServerConfigurationManager's processLoadRequestResponse method. That makes it sound like a new version of the data provided by the server didn't have some field that old versions of the SDK expected, and the old code didn't catch that exception.
- saagarjha 6y ago
  (That’s the old crash.)