Ради потомков: у меня была такая же проблема. В моем случае у меня был объект A с отношением (к одному) к объекту B . Когда A было удалено, обратное отношение B к A было установлено на null. Это вызвало вызов метода B observeValueOfKeyPath:ofObject:change:context (где keypath было отношение B к A ). К сожалению, этот метод проверил свойство A , что привело к отмене сбоя A (обратите внимание, что в этой ситуации awakeFromFetch не вызывается - я предполагаю, потому что объект никогда на самом деле попал в состояние вины). Следовательно, я мог бы получить второй вызов willTurnIntoFault позже, и объект попытался бы снова отменить регистрацию для KVO, что привело бы к сбою - как в OP.
Для меня решение состояло в том, чтобы изменить правило удаления для A на каскадное, чтобы объект B удалялся при удалении объекта A AND , чтобы отменить регистрацию для KVO в prepareForDeletion. Это важно, потому что удаление A все равно приведет к тому, что обратное отношение B будет установлено равным нулю, прежде чем B будет фактически удалено.
Обратите внимание, что prepareForDeletion вызывается до , но не вместо из willTurnIntoFault. Следовательно, если вы отменили регистрацию для KVO в обоих случаях, вам нужно сохранить некоторое состояние, чтобы убедиться, что вы еще не зарегистрированы.