Open Radar

 
Summary:

We caught a very strange KVO bug or race condition in NSOperation. When operation becomes Ready it does not run -start and keeps dangling in operation queue, or it doesn’t call completion block after transition to Finished state.

It’s a race condition because even adding NSLog statement somewhere around KVO notifications helps to delay or temporary or even entirely fix the issue, so behavior is not very consistent and looks like has something to do with timing.

Our code is based on a sample project called Earthquakes that was presented over WWDC 2015 - 226 Advanced NSOperations. 

So we use a subclass of NSOperation that maintains its state and properly handles KVO notifications, which should be enough for NSOperation subclasses to work properly. 

You can follow our investigation on Github:
https://github.com/danthorpe/Operations/issues/175

Also, I’ve attached a sample project that contains an original copy of Earthquakes app presented as a sample code during WWDC session mentioned above. 

The only change was made is contained within AppDelegate (GIST: https://gist.github.com/pronebird/6ccf4e67030f5fdffe65c941c736181c)

The attached project runs operations in loops, you will see that at some point operations stop executing and logging themselves in Xcode console. Then if you enter debugger and print sharedQueue’s contents you will see that some of operations are ready but do not start.

Steps to Reproduce:

Expected Results:
NSOperation should consistently call -start once it becomes Ready and received a KVO notification.

Actual Results:
Operations remain in Ready state, or don’t call completion block after finished, or crash the app.

Regression:

Notes: