Receive notifications of new events get's set to No even when I select Yes on login flow

[DHaussermann]

Receive notifications of new events get's set to No even when I select Yes on login flow. It seems like it does create a subscription for the user but the invites do not get delivered and the user must open the settings panel and change it to yes.

Steps:

• Disconnect the test user
• Connect the test user
• In the Login flow select that you would like to receive notifications for new events
• Complete the login flow
• Open the settings panel

Observed: Receive notifications of new events is set to no

[DHaussermann]

@aaronrothschild can you advise on a milestone for this. Maybe @larkox has input on if the fix is small or not.

[larkox]

Cannot reproduce on master 🙁

[DHaussermann]

Strange. More details:

• I have the latest master b549fad
• Reproduced with 2 different users
• Reproduced on Chrome and Browser

[larkox]

I still cannot reproduce it 😓 What appears if you do /mscalendar subscribe list? If the list is empty, confirm you can do /mscalendar subscribe, and then typeagain /mscalendar settings to refresh the panel, and see the value.

Finally, if the /mscalendar suscribe list is empty after setting the value after the login flow, double check there is no related server error (might be a "integraton error" and not exactly mscalendar error).

[DHaussermann]

@larkox I noticed that this does not happen with all the user on my local. Furthermore, when I deploy master branch to a new cloud server, I cannot reproduce it.

Maybe this is somehow causes by cases of bad data?

[larkox]

There might be some problem with "lingering subscriptions". In theory, if there is already a subscription, it will not create a new one. I could double check that logic to get rid of lingering subscriptions. Nevertheless, it should not be a big of an issue in standard environment (I think).

[larkox]

Due to how things are handled in the code, if we have a subscription on Microsoft side that is not associated to the user for some reason (code errors somewhere else mainly), the flow will consider the subscription "existent" and will not create a new one, and therefore, will not associate a subscription to the user.

This should happen to the same users on all instances since it is something depending on how things are on the Microsoft side, and not on the plugin side. Nevertheless, subscriptions have a "short life", so once those subscriptions expire, those users should be "fixed" on all instances.

[larkox]

@DHaussermann I uploaded a potential fix if my supposition is correct. I leave to you to decide whether this fix should make it for 0.1.0 or 0.2.0.

[DHaussermann]

@larkox do we have any idea how prevalent this is or how it occurs? Unless @aaronrothschild has any objections, I think it should go into 1.0.0.

On a related note I discovered yesterday for my affected users on my local that flushing the KV store does not resolve the issue. Though I suspect you're already aware of that if you have a potential solution.

[larkox]

@DHaussermann Deleting an user from the KVStore without removing the subscriptions might provoke this. If you do that, the plugin will never remove the subscription on Microsoft side, and when you authenticate the new user, it will have a Subscription on Microsoft side but none on local.

The only "natural" way for this to happen, would be that there is some error deleting the subscription while deauthenticating the user.

[aaronrothschild]

@larkox do we have any idea how prevalent this is or how it occurs? Unless @aaronrothschild has any objections, I think it should go into 1.0.0.

No objections...