If reachability changes quickly enough (which was occurring a bunch during unit testing, but less likely in real life situations), if checkAndRestoreFrozenOperations is called while freezeOperations is still running, ops can be stuck in a frozen state until the next reachability change. Below is an outline of what was happening when I was unit testing a piece of my app and also explains why I was randomly seeing that operations were not being completed once connectivity was restored...
Assume an operation has been created and is in the operation queue.
When reachability changes to NotReachable, the freezeOperation function is called by MKNetworkEngine.
The freezeOperation function will attempt to freeze all operations in the queue, currently there is only one operation in the queue.
Before freezeOperation actually freezes the op to the file system, reachability changes and checkAndRestoreFrozenOperations is called to restore the frozen operations.
checkAndRestoreFrozenOperations checks the file system for frozen operations to restore. Since freezeOperation hasn't written the op to the file system yet, checkAndRestoreFrozenOperations thinks there's nothing to unfreeze so completes without doing anything.
Now control returns back to freezeOperation and it writes the frozen operation to the file system. However, since checkAndRestoreFrozenOperations was already called, this operation will be stuck there until the next time reachability changes from unreachable to reachable.
If reachability changes quickly enough (which was occurring a bunch during unit testing, but less likely in real life situations), if checkAndRestoreFrozenOperations is called while freezeOperations is still running, ops can be stuck in a frozen state until the next reachability change. Below is an outline of what was happening when I was unit testing a piece of my app and also explains why I was randomly seeing that operations were not being completed once connectivity was restored...