How to correctly use updateDocumentWithID?

[cerupcat]

I've defined a method stub where I'd like to update the count field optimistically and use latency compensation.

NSUinteger count = 10;
// define stub
[Meteor defineStubForMethodWithName:@"createNote" usingBlock:^id(NSArray *parameters) {
            NSString *documentId = [parameters objectAtIndex:1]; // temporary
           [Meteor.database collectionWithName:@"notes"] updateDocumentWithID:documentId changedFields:@{ @"count" : @(count+1)}];
            return nil;
        }];

// call the method
[Meteor callMethodWithName:@"createNote" parameters:parameters completionHandler:nil];

The stub correctly called and the update is correctly updated locally. However, once the method completes and is returned from the server, another update notification is sent and the count field is overridden with the previous value despite the method return not sending any fields. Is this the correct behavior? How can I update a document locally without it being overridden (unless the document is changed from the server - which in this case it isn't).

Also, trying to call updateDocumentWithID outside of a defineStubForMethodWithName block returns:

2017-05-19 15:59:16.283304-0700 EPop-Debug[23907:7676327] message {
    error =     {
        error = 404;
        errorType = "Meteor.Error";
        message = "Method '/collectionName/update' not found [404]";
        reason = "Method '/collectionName/update' not found";
    };
    id = E88igbFFzscAxn9mq;
    msg = result;
}

[martijnwalraven]

Yes, that is expected behavior. Optimistic updates are always completely rolled back after a server response, because the server is the single source of truth. If you want to update count permanently, you should add the same logic to the server-side createNote method.

[cerupcat]

Gotcha, that makes sense. In our case, while the server does update the count, it's not a reactive update which is why it's restored. Using performUpdatesInLocalCache looks to be the solution we need in this case. Since we know if the server succeeds, we can make the change locally without having the server make this field reactive.