This was requested multiple times here , but the topic was closed without a useful response.
In previous versions of the Intercom SDKs, logging in and out was idempotent: if we called login more than once with the same user ID (or log out more than once), it wouldn’t give any error. That’s no longer the case on the latest versions, and this presents a problem.
The SDK persists the user’s login state between launches but doesn’t expose its user state, so the only way an app can avoid calling login with the same user details the next time the app runs (which would cause the SDK to throw an error), is by also persisting the user log in state via its own method, in hope of remaining in sync with the SDK’s login state. However, this is problematic: state persistence is error-prone, and if an error occurs with either the app’s or the SDK’s persistence, the two can get out of sync, and the SDK will throw an error and leave the app in an inconsistent state.
There are two options for the SDK to eliminate these risks, either :
- make the login and logout calls idempotent once more, so that for example, calling login with the same user id as the current Intercom user does not throw an error, OR
- make the currently logged in user’s user id / email available in the SDK, so that the app code knows when it can avoid calling login and logout unnecessarily.
Please give this feature request proper consideration.
Best answer by Eden
View original
