Open Radar

 
Summary:

I have a UITableViewController with an NSFetchedResultsController as its data source, using change tracking. I make changes to Core Data objects on a background thread and then use a notification to progagate the changes to the main thread's context, which the FRC is connected to.

The FRC is sorted on the 'SortBy' field which is an Integer32. I'm not using sections or caching in the FRC.

Steps to Reproduce:

Initially the table looks like this 

1. Title: t1, SortBy: 0
2. Title: t2, SortBy: 1
3. Title: t3, SortBy: 2
4. Title: t4, SortBy: 3
5. Title: t5, SortBy: 4

Then in a background thread, I make the following changes

A) Add a new item: Title: t0, SortBy: 0
B) Delete item t5
C) Increment SortBy of the existing rows by 1. _except_ for item t3

In other words, I want to insert a new row at the top, move the rest down, but keep t3 at the same location.

Then save and let the changes propagate to the main thread via notification. And let table be updated by FRC change tracking.

Expected Results:

The table should look like this:

1. Title: t0, SortBy: 0
2. Title: t1, SortBy: 1
3. Title: t3, SortBy: 2 <- t3 stays at row 3
4. Title: t2, SortBy: 3
5. Title: t4, SortBy: 4

Actual Results:

The table actually looks like this:

1. Title: t0, SortBy: 0
2. Title: t1, SortBy: 1
3. Title: t2, SortBy: 3 
4. Title: t3, SortBy: 2 <- t3 is in the wrong spot and SortBy is not honored
5. Title: t4, SortBy: 4

Notes:

I don't think its the same bug as the url describes (because the work around suggested doesn't help):
http://developer.apple.com/library/ios/#releasenotes/iPhone/NSFetchedResultsChangeMoveReportedAsNSFetchedResultsChangeUpdate/index.html#//apple_ref/doc/uid/TP40009210

After the update runs, the table view is in the wrong order, but if I kill the app and restart it, the table view loads in the correct order, so the data is correctly updated and persisted, its just that the FRC isn't updating its in-memory state correctly.