Handling Interrupts on Refresh in LangGraph

[tender mountain]

Hey, quick question - I have interrupt, and I refresh the page, is it possible to receive the interrupt on the same thread after the refresh ? any solutions ?

[sonic garden]

hey @tender mountain ,
you have to do the following:

1. implements a persistence layer to store your chat history (check out https://docs.copilotkit.ai/langgraph/persistence/message-persistence)
2. track the threads history so you can later on load a thread by its ID (either via localstorage, or another database, you just need to store the thread ID to use later on) ( for now start by setting threadID statically e.g.,<CopilotKit threadId={"DDD-XXX-555}>
3. implement your aqgent behavior and test it it should work

notice: you sould use copilotkitRemoteEndpoint to set up your backend agent otherwise if you are using AG_UI-based-implementation its broken and not working, read: https://discord.com/channels/1122926057641742418/1412094210688946397

[tender mountain]

I have postgres checkpointer and tracking the thread id in a separate table too , I able to retrieve the messages , but the interrupt only is not appearing though 🙄

ps: using copilotkitRemoteEndpoint

[sonic garden]

if your history reloads correctly it should work

[tender mountain]

this is the current behaviour 🙂

[woeful flax]

Here's what I found regarding interrupt persistence:
Interrupts don't persist across page refreshes in LangGraph - they're stored in React Context which gets lost on refresh. While thread persistence (conversation history/agent state) works with thread IDs and backend storage, interrupt persistence isn't built-in. You may have to implement

• Custom persistence using localStorage/sessionStorage or backend storage
• Handle interrupts as part of conversation state instead

[tender mountain]

I wanted to support multiple users working on the same thread, so using state seems like a good approach.

I also noticed that if I refresh the page while on the same thread, new messages don't arrive. It looks like the state is being cached by CopilotKit. I ended up extending the class to retrieve the synced state