Skip to content

feat(cloud-agent-next): add async session preparation with fast response#1151

Open
eshurakov wants to merge 2 commits intomainfrom
eshurakov/cloud-agent-next-fast-response
Open

feat(cloud-agent-next): add async session preparation with fast response#1151
eshurakov wants to merge 2 commits intomainfrom
eshurakov/cloud-agent-next-fast-response

Conversation

@eshurakov
Copy link
Contributor

@eshurakov eshurakov commented Mar 16, 2026

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.

  • Fast return path: autoInitiate: true flag on prepareSession returns immediately after creating IDs and registering minimal DO metadata. Expensive work (git clone, setup commands, kilo server start) runs asynchronously via a DO alarm.
  • Single stable ID: Generate a 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.
  • Streaming progress: New preparing event type streams real-time preparation steps (disk check → clone → branch → setup → ready/failed) over the existing WebSocket infrastructure.
  • Chat page integration: WebSocket connects during async preparation to display progress events. Auto-initiates execution once preparation completes. New progress status indicator (muted spinner, no auto-clear).
  • Cold-start resume progress: Threaded onProgress callback 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 on ctx.waitUntil which is a no-op in DOs). cli_sessions_v2 is created before return so the stream-ticket route can verify ownership immediately. restore-session.ts gains a --file flag to accept pre-written session files for import (Docker rebuild needed).

Verification

  • Manual check

Visual Changes

Before After
Landing page blocks 10–30s during prepareSession before redirect Redirects in ~500ms; chat page shows streaming progress (disk check → clone → setup → ready)
No progress during cold-start resume on follow-up messages Progress spinner for each cold-start step (clone, workspace setup, session restore, kilo start)

@eshurakov eshurakov marked this pull request as ready for review March 17, 2026 08:55
@kilo-code-bot
Copy link
Contributor

kilo-code-bot bot commented Mar 17, 2026

Code Review Summary

Status: 3 Issues Found | Recommendation: Address before merge

Fix these issues in Kilo Cloud

Overview

Severity Count
CRITICAL 0
WARNING 3
SUGGESTION 0
Issue Details (click to expand)

WARNING

File Line Issue
cloud-agent-next/src/router/handlers/session-prepare.ts 203 autoInitiate still blocks on synchronous GitHub App lookup/token generation before returning
cloud-agent-next/src/persistence/CloudAgentSession.ts 1003 Auto-initiate failure leaves the session marked initiated even though the initial prompt never ran
cloud-agent-next/src/persistence/CloudAgentSession.ts 1159 alarm() still reuses a pre-preparation timestamp for later timeout checks after long async preparation
Other Observations (not in diff)

Issues found in unchanged code that cannot receive inline comments:

N/A

Files Reviewed (26 files)
  • cloud-agent-next/Dockerfile.dev - 0 issues
  • cloud-agent-next/src/execution/orchestrator.ts - 0 issues
  • cloud-agent-next/src/persistence/CloudAgentSession.ts - 2 issues
  • cloud-agent-next/src/persistence/async-preparation.ts - 0 issues
  • cloud-agent-next/src/persistence/schemas.ts - 0 issues
  • cloud-agent-next/src/router/handlers/session-prepare.ts - 1 issue
  • cloud-agent-next/src/router/schemas.ts - 0 issues
  • cloud-agent-next/src/session-ingest-binding.ts - 0 issues
  • cloud-agent-next/src/session-service.ts - 0 issues
  • cloud-agent-next/src/shared/protocol.ts - 0 issues
  • cloud-agent-next/src/types/ids.ts - 0 issues
  • cloud-agent-next/src/utils/kilo-session-id.ts - 0 issues
  • cloud-agent-next/wrangler.jsonc - 0 issues
  • cloud-agent-next/wrapper/src/restore-session.ts - 0 issues
  • cloudflare-session-ingest/src/dos/SessionIngestDO.ts - 0 issues
  • cloudflare-session-ingest/src/session-ingest-rpc.ts - 0 issues
  • src/app/api/cloud-agent-next/sessions/stream-ticket/route.ts - 0 issues
  • src/components/cloud-agent-next/CloudChatContainer.tsx - 0 issues
  • src/components/cloud-agent-next/CloudNextSessionsPage.tsx - 0 issues
  • src/components/cloud-agent-next/SessionStatusIndicator.tsx - 0 issues
  • src/components/cloud-agent-next/store/atoms.ts - 0 issues
  • src/components/cloud-agent-next/useCloudAgentStream.ts - 0 issues
  • src/lib/cloud-agent-next/cloud-agent-client.ts - 0 issues
  • src/lib/cloud-agent-next/websocket-manager.ts - 0 issues
  • src/lib/cloud-agent/stream-ticket.ts - 0 issues
  • src/routers/cloud-agent-next-schemas.ts - 0 issues

Reviewed by gpt-5.4-20260305 · 3,058,793 tokens

eshurakov added a commit that referenced this pull request Mar 17, 2026
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.
Base automatically changed from eshurakov/cloud-agent-random-port to main March 17, 2026 11:35
await this.recordKiloServerActivity();

// 11. Emit ready
emitProgress('ready', 'Session ready');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@eshurakov eshurakov force-pushed the eshurakov/cloud-agent-next-fast-response branch from b8e8cfc to 1d1bfa7 Compare March 17, 2026 16:16
…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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants