feat: add forceReleaseLock + onLockConflict for interrupt/steerability

[gakonst]

Problem

When building AI agents on top of the chat SDK, users need to be able to interrupt a running agent by sending a follow-up message. Currently, if a handler is still processing (e.g., streaming an LLM response), the thread lock blocks the new message and it gets silently dropped via LockError.

This makes it impossible to steer or interrupt long-running agent turns from chat.

Solution

Two changes:

1. StateAdapter.forceReleaseLock(threadId) — unconditionally releases a thread lock regardless of ownership token. The previous lock holder's finally block will call releaseLock() with a stale token, which is already a no-op (both Redis and memory impls verify the token before deleting).

2. onLockConflict config option — controls behavior when acquireLock fails:

   • 'drop' (default, preserves current behavior) — throw LockError
   • 'force' — force-release the existing lock and re-acquire
   • (threadId, message) => 'force' | 'drop' — callback for custom logic

const chat = new Chat({
  userName: 'my-bot',
  state: createRedisState(),
  onLockConflict: 'force', // always allow interrupt
});

Why this matters

Any chat SDK user building long-running handlers (AI agents, workflows, async tasks) needs this. The current lock-or-drop behavior was designed for short idempotent handlers, not multi-minute streaming sessions. This is a non-breaking, backwards-compatible addition.

[vercel]

@gakonst is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
chat	Ready	Preview, Comment, Open in v0	Mar 8, 2026 7:41am
chat-sdk-nextjs-chat	Ready	Preview, Comment, Open in v0	Mar 8, 2026 7:41am

[haydenbleasel]

great stuff @gakonst 🙏