Under review

Duplicate address error when adding members to Google Groups

Hayden Gray 3 weeks ago in UNIFYBroker/Google Apps updated by Beau Harrison (Software Engineer) 3 weeks ago 1

Hi All,

I am currently assisting a client with an issue in UNIFYBroker, whereby a Google Group connector, is reporting a duplicate account error for some users when trying to added them to google groups. We can inspect the groups manually in google and these groups definitely do not contain these users. Being unable to find a root cause for the issue in Broker/MIM, the client raised a ticket with Google and received the following response:

Thank you for contacting Google Cloud Support. I understand that you are not being able to add an address to one of your Groups as you are getting a message that the address has already been to the Group.

I reviewed the information you provided on the chat and did the checks we do in this cases. The reason you are not able to add the external address is because the address you are trying to add is either an alias, a contact or a recovery address for a Google account. The system has the Google account already associated to the Group and since the system already knows the main account is already added it does not let you add it again. In this case you will need to contact the external user and ask for an alternate address they may have and check if that address is already on the Group. The other address is already receiving the messages sent to the Group.

Not being able to find a solutions around this within Broker and MIM I was hoping you may be able to take a look and see if you can spot anything we may be missing here.

This issue has quite a big of attention within the client environment as key people are missing out on important Covid-19 information. The current work around is listed in Google's response, however this often takes weeks to remediate.

Let me know if you need any further information.


Affected Versions:
Fixed by Version:
Under review

Hi Hayden

After discussing this, it was decided that as a temporary solution we would implement the changes we talked about last week. However as I've been doing this work, I've noticed some things that do not add up.

Firstly, my understanding it that this issue was caused by adding an account or email being added to a group when another account has that email as their recovery address. I have not been able to replicate this. I've tried both internal and external members, as well as adding the recovery address both before and after the other account. Perhaps there is a setting somewhere for disallowing this that I don't have enabled in my dev environment? Can you try and find more information about this events that cause this issue? Is it actually a recovery relationship, and if so what order are the members added and is one of them an external member or are both internal members?

The other dependency is the claim that the duplicate member errors are causing other accounts to not be placed into groups if they would have been processed after the failing one. Last week I incorrectly stated that that group member processing would halt if an error occurred part way though. Digging into the code this week I've realised this is not the case, the error is just logged. Sorry for the confusion. Are there any documented cases of members not being correctly added to group without a logged error, or is this aspect of the issue based on the bad information I provided?

Finally, while debugging, I came across an issue that could cause group connector imports not properly populate the internal membership fields in certain situations. Unsure if it could have contributed to this issue, but here's a patch anyway.