Agent conversation history stored in-memory — lost on server restart, breaks multi-instance deploys

[CodewMilan]

Bug Report

Description

ui/app/api/agent/route.ts stores conversation history in a module-level Map.
This means:

• All history is wiped on every server restart or hot reload
• The app cannot scale to more than one process (Vercel serverless, multiple dynos, etc.)
• Two users on the same session ID will share history if both hit different instances

Affected file

ui/app/api/agent/route.ts

Acceptance criteria

• Conversation history survives a next dev restart
• Two separate Node processes serve the same history for the same session_id
• History is cleaned up after a configurable TTL (e.g. 24 h)

[nayanikavyas274-cmyk]

hey @CodewMilan , i would like to work on this issue , can you assign it to me !

[nayanikavyas274-cmyk]

hey @CodewMilan
After reviewing route.ts, there's no module-level Map , the route is stateless and receives full message history per request. The actual gap is that AgentChat stores messages in useState, which is lost on page refresh. should i open a PR to persist history to Supabase with TTL ?

[ansu555]

Hey @CodewMilan
I spent some time on the app/api/agent/chat/route.ts . As you mention a " module-level Map conversation history." Looking at your actual code, that specific bug doesn't exist here. There is no Map, no session storage, and no server-side history at all in this file.
I also verified through Claude, same response.

In this file, the route.ts is stateless by design. The client owns the conversation history

// The client sends the full history on every request
const { messages, publicAddress } = (await request.json()) as {
  messages?: ChatMessage[]   // ← full history sent from the browser
  publicAddress?: string | null
}

The server just prepends a system prompt and forwards everything straight to Groq. Nothing is stored server-side, nothing is shared between processes, and nothing gets wiped on restart. The Map from the bug report simply isn't here.

The Real Problem

The actual gap is in the frontend. AgentChat stores messages in useState, which means history is lost on every page refresh. That's the problem worth fixing.

My Proposed Fix: localStorage (not Supabase)

Supabase would be the right call if the project later adds user accounts or cross-device sync but for the current requirement, localStorage covers it with no new infrastructure.

1. Matches the existing architecture :

The route is stateless, and the client already owns the full message history. Persisting it in localStorage keeps that model intact, no backend changes needed.

2. Consistent with the existing codebase :

already uses localStorage for similar data PROJECT_STORAGE_KEY in DevKit, stellar_devkit_plan_order for payment state, network profile. Using it for chat history follows the same pattern.

3. No auth or identity required :

There's no user account tied to chat. Supabase would require something to key sessions by — wallet address, anonymous ID, etc. localStorage is keyed by browser origin and just works.

4. Privacy :

Chat messages can contain wallet addresses and token amounts. Keeping history only on the client means it never leaves the user's browser.

5. TTL is straightforward to implement

// Save with timestamp
localStorage.setItem("agent_chat_history", JSON.stringify({
  messages,
  lastActivityAt: Date.now(),  // updated on every message, not just on mount
}))

// Load with TTL check
const TTL_MS = 24 * 60 * 60 * 1000 // 24h — make this an env-configurable constant

const raw = localStorage.getItem("agent_chat_history")
if (raw) {
  const { messages, lastActivityAt } = JSON.parse(raw)
  if (Date.now() - lastActivityAt < TTL_MS) {
    setMessages(messages)
  } else {
    localStorage.removeItem("agent_chat_history") // stale — evict cleanly
  }
}

When Supabase Would Actually Make Sense

Supabase becomes the right call if the project later adds:

• User accounts (e.g. wallet-based auth)
• Cross-device history sync
• Server-side analytics on conversations

None of those are current requirements, so adding a database dependency now would be premature.

Summary

Factor	localStorage	Supabase
Survives page refresh	✅	✅
Survives server restart	✅	✅
Implementation effort	Minimal (~20 lines)	Schema + RLS + client + env vars
Auth required	No	Yes
Fits current architecture	Yes	No
Privacy (wallet data)	Stays on client	Sent to server

Happy to open a PR with this approach if it looks good 🚀

[CodewMilan]

hey @nayanikavyas274-cmyk you can start working on this, really sorry about the late response

[nayanikavyas274-cmyk]

Hey @CodewMilan , I made the PR for this issue and described the changes and implementation decisions i took in that , would love to get a review soon!

[nayanikavyas274-cmyk]

hey @CodewMilan can i get a review and if some upgradations are required pls tell !

[CodewMilan]

Please link the pr to the issue

[nayanikavyas274-cmyk]

i have already linked the pr to this issue pls review . PR #28