You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b8c85af
Browse filesBrowse the repository at this point in the historyBrowse files
feat(core,sdk,webapp): version skew protection for chat.agent sessions
A chat session now carries an external deployment id, so every run it schedules
lands on the deployment that matched the app build that started the conversation:
the first run, each continuation after an idle suspend, and each recovery after a
crash.
Public SDK surface:
- `triggerConfig.externalDeploymentId`, on every entry point that starts a session
(`sessions.start`, `chat.createStartSessionAction`, `chat.headStart`,
`chat.handover`, `AgentChat`). Normally omitted: it is discovered wherever the
session is started, with the same precedence `trigger()` uses. `null` opts one
chat out.
- `pendingVersion` on the session-create and `.in/append` responses, on
`ChatStartSessionResult` and on `StartSessionResult`, plus a new
`run-pending-version` transport event, so a chat waiting on a deployment that is
still building can say so instead of appearing to stall.
- `chat.requestUpgrade({ externalDeploymentId })`. Called without a target it
clears the session's pin, which is what makes upgrading away from a pinned
version possible at all, and the cleared pin is persisted so the next
continuation cannot bounce back.
- `SessionTriggerConfigInput` and `CreateSessionInput`, the caller-facing forms of
the trigger config and the create body.
Parking is the right failure mode here, and an improvement on `lockToVersion`,
which throws on session create and is swallowed on the append path, leaving the
chat hung with no run at all. `PENDING_VERSION` is non-final, so a parked run is
reused rather than re-triggered and appended messages stay durable until the
deployment lands.
`chat.requestUpgrade()` reaches the handoff from both its documented call sites.
The post-turn sites — `run()` and `chat.defer()` — persist the handoff directly
rather than going through the upgrade-required chunk, which the pre-turn sites
use; without that, a pinned session's post-turn upgrade was a silent no-op and
every continuation landed back on the deployment the agent had asked to leave.
`lockToVersion` is deliberately untouched: it still wins where both are set, and
`requestUpgrade()` still cannot escape it.
Chat sessions can now be pinned to a deployment, so a conversation keeps talking to the agent version its release shipped with across every turn, idle suspend and recovery. The id is resolved wherever you start the session, exactly as it is for `trigger()`, so there is no chat-specific setup — and if your app sends no id, nothing changes. Pass `triggerConfig: { externalDeploymentId: null }` to opt one chat out.
0 commit comments