setCustomerInfo() does not reliably override restored chat session data

[RogatinAlex]

Summary

We are seeing cases where setCustomerInfo() does not seem to be fully applied to the next chat open.

For some users, the chat opens with:

• an old groupId
• stale customer fields
• mixed/partially outdated customer info

This started to be reported relatively recently, but our Android integration code for opening LiveChat was not changed.

SDK version

• com.github.livechat:chat-window-android:3.0.3

Platform

• Android

Our integration

We set customer data immediately before opening the chat:

LiveChat.getInstance().setCustomerInfo(
    groupId = groupId,
    name = visitorName,
    email = visitorEmail,
    customParams = customParams
)

LiveChat.getInstance().show(context)

groupId and customer fields are recalculated on each open based on the current app state.

Expected behavior

The latest values passed to setCustomerInfo() should be used when the chat is opened with show().

Actual behavior

For some users, the next chat open may still use:

• a previous groupId
• previous customer name/email
• previous or partially stale customParams

Important context

From the documentation, we understand that:

• the chat view is kept in memory by default
• the session is stored in WebView cookies
• customer properties may require recreating the view after the chat has already loaded

However, the behavior we see is still unclear from an integration perspective:

• setCustomerInfo() is called right before show()
• but the resulting chat state may still reflect older data

So our main question is whether this is expected SDK/session lifecycle behavior or a bug/regression.

Reproduction scenario

A simplified scenario:

1. Initialize SDK
2. Call setCustomerInfo(A)
3. Call show()
4. Close chat
5. Change app-side user context / language / group
6. Call setCustomerInfo(B)
7. Call show()

Expected:

• chat opens with B

Observed:

• for some users, chat may still behave as if A is active, especially for groupId and some customer fields

Possible process death scenario

We also suspect the issue may be related to Android process death after the app stays in background for some time.

A possible scenario:

1. User opens chat with setCustomerInfo(A) and show()
2. App goes to background
3. Android kills the app process
4. User returns to the app later
5. App process is recreated
6. We calculate fresh values and call setCustomerInfo(B) before show()
7. Chat still appears to use old session/customer context

From our analysis, this may happen because:

• groupId / customerInfo are stored in the SDK singleton in memory
• after process death, that in-memory state is lost
• but WebView session data / cookies may still persist
• so the restored chat session may take precedence over the newly provided customer info

This makes the behavior unclear from the integration side:

• app-side we provide fresh customer data before each show()
• but persistent WebView session may still restore older state

Questions

Could you please clarify:

1. Is this expected behavior of the SDK/session lifecycle, or could this be a bug/regression?
2. Can restored WebView session/cookies override the latest setCustomerInfo() values?
3. Is destroyLiveChatView() required every time customer data changes?
4. Is signOutCustomer() required when changing user identity or groupId?
5. What is the recommended way to guarantee that newly calculated groupId and customer properties are always applied after process recreation?

Additional note

We can implement a workaround on our side by explicitly calling:

• signOutCustomer()
• destroyLiveChatView()

But before enforcing that, we want to confirm whether this is the intended lifecycle or an issue in the SDK.

[nomyzs]

Hello Alex,

Thanks for reaching out. Let me try to clarify this.

You are correct that the customer session is stored in WebView cookies. However, updating the customer name, email, and custom parameters should normally only require calling setCustomerInfo() before show().

If you are using the default lifecycle scope LiveChatViewLifecycleScope.APP, the chat view is kept in memory. In that case, you should call:

LiveChat.getInstance().destroyLiveChatView()

before calling show(). This forces the chat to reload and ensures the updated customer information is applied.

Important notes

• Any change to customer information requires the chat to be reloaded for the update to take effect.
• Customer group cannot be reassigned while a chat is active.
• Name, email, and custom parameters should be overwritten on the next chat open.
• Providing empty values in a subsequent setCustomerInfo() call will not clear existing customer properties.
• If your setup uses a pre-chat survey with name/email prefilling, those values may appear stale until the user completes the form again — for example when starting a new chat after the previous one has been archived.

You generally should not need to explicitly call signOutCustomer(), since it also destroys the chat view internally. In most cases, calling destroyLiveChatView() after updating setCustomerInfo() is sufficient.

---

Answers to your questions

1. Is this expected behavior of the SDK/session lifecycle, or could this be a bug/regression?

This is how the SDK currently behaves. If you have suggestions for improvements to this behavior, we’d definitely be interested in hearing them.

2. Can restored WebView session/cookies override the latest setCustomerInfo() values?

They generally should not override them, as long as the new CustomerInfo values replace the previous ones and the chat is not currently active when changing the groupId.

3. Is destroyLiveChatView() required every time customer data changes?

Only if you are using LiveChatViewLifecycleScope.APP.
In that mode the chat view is cached, so destroying it ensures the next show() loads a fresh instance.

If you use an ACTIVITY lifecycle scope where the view is recreated automatically, the chat will reload on every show() and this is not necessary.

4. Is signOutCustomer() required when changing user identity or groupId?

It is recommended when switching to a different user identity, to ensure a completely new chat session is created.

For groupId, it’s important to note that group assignment can only change for inactive (closed/archived) chats.

5. What is the recommended way to guarantee that newly calculated groupId and customer properties are always applied after process recreation?

Currently, there is no direct way to detect whether the user already has an active chat session.
If you need to guarantee that the user starts with a fresh session and is assigned to the latest groupId, calling:

LiveChat.getInstance().signOutCustomer()

is the safest option.

Note that signOutCustomer() also calls destroyLiveChatView() internally.

---

If you have additional questions or manage to reproduce a case where the behavior differs from what’s described above, please let us know and we’ll be happy to investigate further.