* Handle ACP `session/load`. Mirrors newSession's auth gate * and connection guard, but resumes an existing on-disk session * via the shared setupSessionFromExisting helper instead of * creating a new one. After the AcpSession is wired up, replays the * persisted history
(params: LoadSessionRequest)
| 355 | * deliberately skips it (per ACP spec G4 / plan gap-4.3). |
| 356 | */ |
| 357 | async loadSession(params: LoadSessionRequest): Promise<LoadSessionResponse> { |
| 358 | const { session, acpSession, configOptions } = await this.setupSessionFromExisting({ |
| 359 | cwd: params.cwd, |
| 360 | sessionId: params.sessionId, |
| 361 | mcpServers: params.mcpServers, |
| 362 | mode: 'load', |
| 363 | }); |
| 364 | // Synchronously replay history — the response must not settle |
| 365 | // until every historical `session/update` has been pushed, |
| 366 | // otherwise the client would race the load completion against |
| 367 | // its own UI bootstrap. This is the ONE difference vs. |
| 368 | // `resumeSession`, which intentionally omits this step. |
| 369 | await acpSession.replayHistory(); |
| 370 | this.scheduleAvailableCommandsUpdate(session.id); |
| 371 | return { configOptions }; |
| 372 | } |
| 373 | |
| 374 | /** |
| 375 | * Handle ACP `session/resume`. Per ACP spec, `session/resume` is the |
no test coverage detected