Bug in Filtered View?

[dispatchqueue]

I replace metadata by using replaceMetadata method.
In the method handleReplaceMetadata of YapDatabaseFilteredViewTransaction, I found this code (https://github.com/yapstudios/YapDatabase/blob/master/YapDatabase/Extensions/FilteredViews/YapDatabaseFilteredViewTransaction.m#L1005-L1018):

    id object = nil;
    if ((sortingMayHaveChanged && sortingNeedsObject) || (filteringMayHaveChanged && filteringNeedsObject))
    {
        object = [databaseTransaction objectForCollectionKey:collectionKey withRowid:rowid];
    }

    [self _handleChangeWithRowid:rowid
                   collectionKey:collectionKey
                          object:object
                        metadata:metadata
                       filtering:filtering
              blockInvokeBitMask:blockInvokeBitMask
                  changesBitMask:changesBitMask
                        isInsert:NO];

sortingMayHaveChanged and filteringMayHaveChanged are NO because the parent view is sorted and filtered by object, so object variable is nil. This object variable is passed to _handleChangeWithRowid.

In the method _handleChangeWithRowid, filteringMayHaveChanged is NO because parent view is filtered by object, and passesFilter is set to YES in the line 834. The filtered view extension will then insert row:

    if (passesFilter)
    {
        // Add row to view (or update position).

        [self insertRowid:rowid
            collectionKey:collectionKey
                   object:object
                 metadata:metadata
                  inGroup:group
              withChanges:changesBitMask
                    isNew:NO];

        lastHandledGroup = group;
    }

At this point, object is nil because it is not get in the code above. And in method insertRowid, the sortingBlock is called with the first object is nil (https://github.com/yapstudios/YapDatabase/blob/master/YapDatabase/Extensions/Views/YapDatabaseViewTransaction.m#L1883-L1896).
object1 and object2 should not be nil in a sorting block, right?

Thanks.

[robbiehanson]

Great catch. Should be fixed in the master branch (and the "v2.8" branch too). Let me know if you have any other issues.