fix: command menu disappears after unmounting and mounting copilot widget back

[maoguy]

Before Widget unmounted and clear the method of window.clearChainlitCopilotThredId, call the window.clearChainlitCopilotThreadId?.();

which can fix the bug : #2384

[xjose97x]

@maoguy I don't quite understand this issue. Could you please provide more details?

[maoguy]

@maoguy I don't quite understand this issue. Could you please provide more details?

Reproduce

To Reproduce,you can try to do that 👇:
1.【Backend】Set the commands and setting in just like👇【docs ref 👉 https://docs.chainlit.io/concepts/command#command】


2.【Frontend】Use the method of window.mountChainlitWidget to mount the widget firstly,so we can see the corrected view 👇

3.【Frontend】Use the method of window.unmountChainlitWidget() to unmount the widget,and then use the method of window.mountChainlitWidget to remount the widget again.At this point, the error occurs👇we can not see the commands menu.

Possible cause

I believe the root cause is that after the plug-in was uninstalled and remounted, no new session was initiated.Therefore the websocket of backend don`t know when should push the new config again.👇

[xjose97x]

@maoguy Oh, understood. I'll take a look at this case during this week.

[hayescode]

@maoguy does #2393 fix this for you?

[maoguy]

@maoguy does #2393 fix this for you?

I try to pull the pr to test，the new commands UI is very nice！👍
But Unfortunately, it still doesn’t solve my problem.😂

95b690dce199296ace3b911adf628f39.mp4

[xjose97x]

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix.
I'm currently doing some research on this and will provide a PR once I find the root cause.

[maoguy]

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix. I'm currently doing some research on this and will provide a PR once I find the root cause.

I believe the plugin should expose configurable lifecycle hooks—such as a "afterMounted" that fires once the plugin is successfully mounted,or a "beforeUnmounted" hook that is invoked right before the plugin is torn down.

With either of these two lifecycle hooks available, we could call window.clearChainlitCopilotThreadId inside mountedCallback (to start a fresh session after remount) or inside beforeUnmounted (to clean up the current session before the plugin is torn down), ensuring the thread ID is properly reset.

[maoguy]

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix. I'm currently doing some research on this and will provide a PR once I find the root cause.

I think the root cause is that after the browser-side plugin is unmounted and remounted, the server is unaware of the change, so the WebSocket-based set_commands event is never pushed.

[xjose97x]

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix. I'm currently doing some research on this and will provide a PR once I find the root cause.

I think the root cause is that after the browser-side plugin is unmounted and remounted, the server is unaware of the change, so the WebSocket-based set_commands event is never pushed.

I believe the correct fix would be to store the set_commands event in the persistence layer—likely by converting it into a Step.
That way, when the widget is remounted and the message history and steps are reloaded, the commands will be restored automatically.

[maoguy]

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix. I'm currently doing some research on this and will provide a PR once I find the root cause.

I think the root cause is that after the browser-side plugin is unmounted and remounted, the server is unaware of the change, so the WebSocket-based set_commands event is never pushed.

I believe the correct fix would be to store the set_commands event in the persistence layer—likely by converting it into a Step. That way, when the widget is remounted and the message history and steps are reloaded, the commands will be restored automatically.

The proposed fix in this PR changes the threadId on every remount. I don't believe this is the right fix. I'm currently doing some research on this and will provide a PR once I find the root cause.

I think the root cause is that after the browser-side plugin is unmounted and remounted, the server is unaware of the change, so the WebSocket-based set_commands event is never pushed.

I believe the correct fix would be to store the set_commands event in the persistence layer—likely by converting it into a Step. That way, when the widget is remounted and the message history and steps are reloaded, the commands will be restored automatically.

Could this approach be interpreted as modifying the react-client layer to persist a copy of the commandsState—a global state managed by Recoil—into localStorage?☺