3 ms·

That means people should reevaluate the weight of the opinions of those technically competent posters - we have a screen shot that robinhood did roll their own

That means people should reevaluate the weight of the opinions of those technically competent posters - we have a screen shot that robinhood did roll their own implementation because yesterday was March 2nd and its app was requesting March 3rd. That at least means that some portion of their stack used roll your own datetime library. That would not actually be a problem as long as the entire stack got the same library or the same rules for datetime. The problem is of course that it probably did not so the libraries were not bug compatible which of course caused errors and those errors need to be handled, preferably every fast. Error load and error handling is the least tested part of every system because it can only be properly tested in production and, unless your company embraces the Chaos Monkey approach to testing, the C-level would have a heart attack when anyone proposes doing it.

vsareto 7y ago
That particular API endpoint is just returning market open times, in which a request for tomorrow might be perfectly reasonable. https://api.robinhood.com/markets/XASE/hours/2020-03-03/ https://api.robinhood.com/markets/XASE/hours/2020-03-03/ vs https://api.robinhood.com/markets/XASE/hours/2020-03-07/ https://api.robinhood.com/markets/XASE/hours/2020-03-07/ This whole discussion lacks context to the nature of the requests, aka a front end code review.
- notyourday 7y ago
  The issue is going to end up being related to some sort of date being injected by the front-end and propagating that incorrect date into the infrastructure. Somewhere within the infrastructure there's going to be an assertion such as if (max_drift_delta > delta(order_live_date,system_live_date) { # oh crap, something is completely broken in our system where did this come from? blow_up("terrible things are happening! how did we get this order") } which is an excellent and correct catcher for "terrible things are happening" since those things should never happen. That blow_up() code path is likely to be very expensive which kills performance of the system, which in turn means that it no longer can handle the load. And since RH has lots of people who use apps, it is not that they can just push an immediate bugfix.
- notyourday 7y ago
  This definitely does not come from a front-end: https://twitter.com/jhyu/status/1234617361467990018 https://twitter.com/jhyu/status/1234617361467990018

vsareto 7y ago

That particular API endpoint is just returning market open times, in which a request for tomorrow might be perfectly reasonable. https://api.robinhood.com/markets/XASE/hours/2020-03-03/ https://api.robinhood.com/markets/XASE/hours/2020-03-03/ vs https://api.robinhood.com/markets/XASE/hours/2020-03-07/ https://api.robinhood.com/markets/XASE/hours/2020-03-07/ This whole discussion lacks context to the nature of the requests, aka a front end code review.

notyourday 7y ago
The issue is going to end up being related to some sort of date being injected by the front-end and propagating that incorrect date into the infrastructure. Somewhere within the infrastructure there's going to be an assertion such as if (max_drift_delta > delta(order_live_date,system_live_date) { # oh crap, something is completely broken in our system where did this come from? blow_up("terrible things are happening! how did we get this order") } which is an excellent and correct catcher for "terrible things are happening" since those things should never happen. That blow_up() code path is likely to be very expensive which kills performance of the system, which in turn means that it no longer can handle the load. And since RH has lots of people who use apps, it is not that they can just push an immediate bugfix.
notyourday 7y ago
This definitely does not come from a front-end: https://twitter.com/jhyu/status/1234617361467990018 https://twitter.com/jhyu/status/1234617361467990018