NSInternalInconsistencyException for seemingly no reason

[wdcurry]

I am using Bolts via Parse, and am seeing an untrappable bolts error, with Bolts trying to set an error, with no error except the faulted = YES .. with no hint, no clue, no ANYTHING except a stopped app.

The ONLY thing changed between a working app and this was UI settings of another view, a child of the offending view.

Unsettling that Bolts is giving nothing to act on yet is stopping my app from running. For now i am going to toss in a check for a nil error and ignore, but this is frustrating. ;)

The stoppage occurs in:

(void)setError:(NSError *)error { if (![self trySetError:error]) { [NSException raise:NSInternalInconsistencyException format:@"Cannot set the error on a completed task."]; } }

I have no clue how to better describe this, and will try. The last time this happened, i simply stepped back an entire coding day and rebuilt, testing each save and got past the point of the last occurrence, which shows me it is not grounded in that which i am doing but in something very fuzzy.

Same thing happened today, but i will only lose about 2 hours of work to rebuild.

[wdcurry]

Bolts stops the app here:

• (void)setError:(NSError *)error {
  if (![self trySetError:error]) {
  [NSException raise:NSInternalInconsistencyException
  format:@"Cannot set the error on a completed task."];
  }
  }

ALL this starts with the load operation of a PFQueryTableViewController as follows, reiterating that nothing in this ViewController was touched prior to the start of the errors. I have tagged the Parse guys from their Google Group to help:

- (BFTask *)loadObjects:(NSInteger)page clear:(BOOL)clear {
    self.loading = YES;
    [self objectsWillLoad];

    BFTaskCompletionSource *source = [BFTaskCompletionSource taskCompletionSource];

    PFQuery *query = [self queryForTable];
    [self _alterQuery:query forLoadingPage:page];
    [query findObjectsInBackgroundWithBlock:^(NSArray *foundObjects, NSError *error) {
        if (![Parse isLocalDatastoreEnabled] &&
            query.cachePolicy != kPFCachePolicyCacheOnly &&
            error.code == kPFErrorCacheMiss) {
            // no-op on cache miss
            return;
        }

        self.loading = NO;

        if (error) {
            _lastLoadCount = -1;
            [self _refreshPaginationCell];
        } else {
            _currentPage = page;
            _lastLoadCount = [foundObjects count];

            if (clear) {
                [_mutableObjects removeAllObjects];
            }

            [_mutableObjects addObjectsFromArray:foundObjects];
            [self.tableView reloadData];
        }

        [self objectsDidLoad:error];
        [self.refreshControl endRefreshing];

        [source setError:error];
    }];

    return source.task;
}

[wdcurry]

For what it is worth, the app continues to work perfectly with this:

- (void)setError:(NSError *)error {

    if (!error) {
        NSLog(@"Bolts bug: setting nil error (their bug): %s", __PRETTY_FUNCTION__);
        return;
    }

    if (![self trySetError:error]) {
        [NSException raise:NSInternalInconsistencyException
                    format:@"Cannot set the error on a completed task."];
    }
}

On a fresh load of two rows, it gets hit 4x. On return to the view from a pushed view, it gets hit only once. This may provide a clue..

[wdcurry]

And i did a simple textual comparison of the h&m files, and there were no changes at all. This seems to hint at something amiss via IB perhaps? Thus far, i am stumped for a strong indicator of the issue. It only manifests in this one view, which has nothing cutting edge on it at all..

[wdcurry]

to continue my monologue: i rebuild all the lost work from the last good backup to the messed up version, documenting each step, and got to the point where the Bolts errors started and no issue at all. So clearly (at least to me) there is something internal to Bolts that is very sensitive to some activity with IB (as that is were most of the effort was) and yet this makes little sense.

Perhaps there is something in how i work, via copy and pasting existing code etc that causes this. It cannot be the code itself as i copied the exact code that lead to the situation.

Very puzzling.

[wdcurry]

It happened again today, for no reason.

Even odder, and perhaps a clue. I simply ran the app on my device (not in debug mode), and it continued to work past the Bolts barf point while in debug mode. That is it, i am simply patching Bolts and moving on, and this is clearly an internal bug to either Parse or Bolts.

[dbarabander]

+1 @wdcurry . I have the exact same thing, and posted in ParseUI. You can see here: https://github.com/ParsePlatform/ParseUI-iOS/issues/108

[kwkhaw]

+1 @wdcurry Thanks for the workaround. I encountered the same error when porting Anypic to Swift https://github.com/kwkhaw/SwiftAnyPic. I ended up by forking the Bolts-iOS and applied the workaround.

[tzapu]

could this be included in the master at any point?
works for me as well

[gadu]

For what it's worth, this happened to me because of a caching issue, as soon as I changed the cachePolicy to kPFCachePolicyNetworkElseCache it stopped...

[ryancrosby]

I have ran into this problem a few times as well, the recent time was due to me calling loadData while the controller was already loading. I still can't determine what is actually causing setError to be called when the task is completed though.

[tzapu]

error also went away for me when i changed to kPFCachePolicyNetworkElseCache

[wdcurry]

The error may disappear, but this pushes the caching behind the network call.. not ideal.

[arcadiaswx]

Any news on Parse updating to incorporate the workaround? Or do we need to fork our own and make the changes?

[arcadiaswx]

I keep having issues with the Bolts library. Says No such File or directory. I rebuild and it finds the previous file, but comes up with another bolts file not found. I am wondering if this has to do with the location of my project being on an external drive.

[nlutsenko]

Hey guys, I am going to close out this issue, since it looks like it's resolved.
Please let me know otherwise by commenting here or reopening it.

[dbarabander]

@wdcurry workaround did the trick

[wdcurry]

glad to help @dbarabander .. little tips like this can help make small-shop coders as effective as the big-boys!