Possible explanation for a number of the reported issues - Google Limit of...

I should have replied here - dup msg as I'm not sure I can delete the other -
Florian - Can you explain the 250 page size. For example if I want to block lunch time for the year, would that fail - it being 260 weekdays?

Hi, I think setting the pageSize manually doesn't have any risk, because also if not set, there is a default pageSize. In the past (before switching from old GoogleContact API to GooglePeople API, we had a fetch size of 256 already and it worked much better than today, we never had this kind of issues with the old GoogleContact API. But it is like it is, Google ended support for GoogleContact API, and we have to live with it and fix/workaround the issues we inherit now. I tested it also on my side with ~600 contacts and at least it worked fine with pageSize 256. But you are right, it will not fix the limit of 1000 contacts to be created. Nevertheless it might fix some overlap issue if there is a problem with fetching the 999th and then the 1000th and then the 1001st contact. maybe there is a bug, because we have these "deleted" issue not only for recreating all contacts, but also for updating. I think there is a Google bug, which somehow doesn't retrieve the one or other contact from Google, and this causes GCSM to think, it was deleted. Therefore I am quite confident, playing around with the page size (choosing a reasonable size) would at least improve the situation. We did already a lot of fixes/workaround to avoid that GCSM thinks, a contact was deleted in new People API, e.g. trying to reload the assumed deleted contact again with several retries, which could cause the performance issues reported, because if this happens frequently (e.g. for each contact between 1000 and 2000), the performance would go down drastically.

In a nutshell: I don't think, the problem comes from creating more than 1000 contacts, I belief it has to do either with the retrieval process (overlapping of fetch pages) or with the hashTag we use, if the id property exceeds the allowed size (e.g. the Google account name is too big to save into Google Property, then we hash it to make a unique, but short id. This hash is different between x86 and 64bit, and beause we recently switched from x86 to 64bit to avoid Memory problems, all ids generated with the x86 version don't match aynmore with the hash we compare in the 64bit. In this case, I always recommend to reset the matches and resync. If you here choose to delete the Google contacts, it will start to recreate all the contacts, and of course, if there are more than 1000, the Google limit will trigger. Here I would then try to NOT delete the Google contacts when asked, because GCSM also tries to match existing contacts by unique properties (e.g. Email or Mobile Phone).

Nevertheless, I think the limit of 1000 creates is annoying, but shouldn't be a problem for GCSM, because if it created already 1000 contacts and fails to create the 1001st, it should show/log an exception and skip the contact (not creating a match yet). The next day when it runs again, it should then create the next 1000 contacts, and so on, until all x000 contacts have been created and matched. From that time on, it should just update, and this should not have any limit. If this is not working like that, e.g. GCSM creates a match but later not finds the match (because not found on Google side) and as a consequence thinks the Google contact was deleted and deletes the Outlook contact, then we should fix this instead, but looking into a code, the match should be created, if Inserting Google Contact fails, see below code. If this is not done, we might have to review all scenarios, if we do this properly in GCSM. Can you try again with latest 4.1.32 version and if still not working, provide us the detailled log?

private void SaveOutlookContact(ref Person gc, ContactItem oc)
{
ContactPropertiesUtils.SetOutlookGoogleId(oc, gc);
Save(ref oc);
ContactPropertiesUtils.SetGoogleOutlookId(gc, oc);
var gc1 = SaveGoogleContact(gc);
if (gc1 != null)
{
gc = gc1;
ContactPropertiesUtils.SetOutlookGoogleId(oc, gc);
Save(ref oc);
if (Synchronizer.SyncPhotos)
{
SaveOutlookPhoto(gc, oc);
}
}
else
{
ContactPropertiesUtils.ResetOutlookGoogleId(this, oc);
Save(ref oc);
}
}

See also Grigios comment in https://sourceforge.net/p/googlesyncmod/bugs/1324: "seems to always happen on the "last + 1" contact.
In my case, I have 564 contacts, and this error appears when GCSM tries to synchronise the "565th contact". It seems to me that GCSM creates this "phantom contact" for some cause...In my case, I have 564 contacts, and this error appears when GCSM tries to synchronise the "565th contact". It seems to me that GCSM creates this "phantom contact" for some cause..."

Hi Chess. I was going through e-mail and saw that I didn't respond to your question. Sorry about that. I'm familiar with the Google contacts import but I've used it on a limited basis only - like to share a subset of my contacts with a family member. I do not know if the Import feature has the same limitation, and at this point, I've been keeping my contacts just below 1000 to avoid the stated limitation; but I'll keep the Import in mind to try if it makes sense later. Thanks.

Hi Adam. As I had mentioned, I ended up just cleaning up my contacts so that they were less then 1000. (I also created single contacts with numerous contacts put in the notes for some groups of contacts that I don't use often). There was some earlier discussion about doing a one-time Outlook export and using the Google import feature, and I think that would likely help.

Adam, I'll just repeat that I had enough issues and strange things happening that I ended up reducing my contacts to under 1000, and I haven't had issues since that time. It's possible that there are some untrapped errors that happen because of the limit that set other things up for failure.