feat(cloud-agent-next): add async session preparation with fast response#1151
feat(cloud-agent-next): add async session preparation with fast response#1151
Conversation
Code Review SummaryStatus: 3 Issues Found | Recommendation: Address before merge Fix these issues in Kilo Cloud Overview
Issue Details (click to expand)WARNING
Other Observations (not in diff)Issues found in unchanged code that cannot receive inline comments: N/A Files Reviewed (26 files)
Reviewed by gpt-5.4-20260305 · 3,058,793 tokens |
Guard cli_sessions_v2 rollback with onlyIfEmpty so records with ingested data are never deleted on preparation failure. Add rollback to the fast path and all early-return paths in runPreparationAsync. Always clean up the --file temp file in restore-session. Use Date.now() instead of a stale capture for alarm rescheduling. Broadcast preparing events without persisting them so stale progress is never replayed on WS reconnect.
| await this.recordKiloServerActivity(); | ||
|
|
||
| // 11. Emit ready | ||
| emitProgress('ready', 'Session ready'); |
There was a problem hiding this comment.
WARNING: ready is emitted before auto-initiate has actually started
emitProgress('ready', ...) runs before startExecutionV2(). The client treats that event as "session initiated" and unlocks the chat input, so if startExecutionV2() then returns an error the user can send follow-up messages to a session that still has no initiatedAt. Emit ready only after auto-initiate succeeds, or use a separate "prepared" state that does not drop the initialization guard.
b8e8cfc to
1d1bfa7
Compare
…tiate ordering and volatile event cursor - Pin SandboxSmall KILOCODE_CLI_VERSION to 7.0.47 (fixes FOREIGN KEY constraint in kilo import that broke session restore) - Pin Dockerfile.dev default to 7.0.47 instead of 'next' tag - Emit 'ready' after successful auto-initiate, not before - Only advance WS lastEventId for persisted events (positive IDs) to prevent volatile events from regressing the cursor
| authToken: input.authToken, | ||
| }); | ||
|
|
||
| if (!initiateResult.success) { |
There was a problem hiding this comment.
WARNING: Failed auto-initiate leaves the session stuck in an initiated state
startExecutionV2({ kind: 'initiatePrepared', ... }) flips initiatedAt before it refreshes GitHub App auth and before executeDirectly() runs. If that call comes back unsuccessful here, this branch only emits failed and returns, so the original prompt never runs but the session still looks initiated on the next load. The chat page then skips auto-initiation and unlocks follow-up input against a session whose initial turn was silently dropped.
Summary
Add an async session preparation path to cloud-agent-next, reducing perceived wait time from 30–120s to ~500ms when starting a session from the landing page.
autoInitiate: trueflag onprepareSessionreturns immediately after creating IDs and registering minimal DO metadata. Expensive work (git clone, setup commands, kilo server start) runs asynchronously via a DO alarm.ses_*session ID upfront in the fast path and import it into the CLI's SQLite before the wrapper starts. Eliminates dual-ID complexity and URL rewriting.preparingevent type streams real-time preparation steps (disk check → clone → branch → setup → ready/failed) over the existing WebSocket infrastructure.progressstatus indicator (muted spinner, no auto-clear).onProgresscallback through the resume path so follow-up messages also report progress during sandbox re-creation.autoInitiate: false(default) preserves existing synchronous behavior exactly — zero changes to existing callers.Architecture: Preparation runs inside the DO via
setAlarm(Date.now()), safe regardless of caller lifetime (no reliance onctx.waitUntilwhich is a no-op in DOs).cli_sessions_v2is created before return so the stream-ticket route can verify ownership immediately.restore-session.tsgains a--fileflag to accept pre-written session files for import (Docker rebuild needed).Verification
Visual Changes
prepareSessionbefore redirect