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 fe5b58e
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 now 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.
`lockToVersion` is deliberately untouched: it still wins where both are
set, and `requestUpgrade()` still cannot escape it.
Chat sessions now stay on the deployment that matched the app build that started them, so a conversation keeps talking to the agent version its release shipped with across every turn, idle suspend and recovery. The id is discovered wherever you start the session, exactly as it is for `trigger()`, so a chat picks up whatever your app already sends when it triggers a task. There is no chat-specific setup.
Messages sent while a chat waits on a deployment that is still building are stored and answered once it lands, and the transport emits a `run-pending-version` event so your UI can say so. `chat.requestUpgrade()` now clears the session's pin so the handoff can reach a new version, and accepts `{ externalDeploymentId }` to move to a specific one.
0 commit comments