{"push_id":586123184,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"0d34d6d353b43660676105f9980191f5dae5be2a","before":"4367546bde320c971170d68b89abb81dbe0b4bc3","commits":[{"sha":"0d34d6d353b43660676105f9980191f5dae5be2a","author":{"email":"0e18f44c1fec03ec4083422cb58ba6a09ac4fb2a@roobiq.com","name":"Adam Fish"},"message":"Issue was found where the FRC because it was dispatch_async its delegate calls, would result in problems if the original change was performed on the main thread. This came about because the UITableView was being called to load during processing and the call to the FRC to give the number of rows in the section already reflected the change to the FRC's cache, but the FRC's delegate's were waiting in the main thread queue to fire. Once they did the UITableView already had \"seen\" the change.\n\nThe fix is to call the FRC's delegate synchronously if we are on the main thread, but dispatch them async if we are not on the main thread. The only time the FRC would be processing on the main thread is in the situation where a change was reported (i.e. the RLMRealm commitTransaction) was on the main thread.... thus everything should just stay synchronous.","distinct":true,"url":"https://api.github.com/repos/Roobiq/RBQFetchedResultsController/commits/0d34d6d353b43660676105f9980191f5dae5be2a"}]}