mirror of
https://github.com/Ark0N/Codeman.git
synced 2026-09-30 20:49:41 +02:00
fix(omp): a fresh "Run OMP" click no longer silently resumes an old conversation
Found live 2026-08-27 by Tim: clicking Run OMP to start a brand-new session in a case directory with prior omp history launched --resume <old-id> instead of a clean `omp` invocation. Root cause: Session._resolvedOmpRespawnConfig() resolves-and-pins the newest on-disk omp conversation as a side effect on this._ompConfig. That is correct when reattaching to an ALREADY-TRACKED mux session (a dead-pane respawn, or a boot-recovery reattach - the constructor sets _muxSession from persisted state before startInteractive() ever runs there), but it ran unconditionally. startInteractive() computes `respawnPaneOptions: this._buildRespawnPaneOptions()` eagerly in the same object literal that builds `createSessionOptions.ompConfig: this._ompConfig`, so for a genuinely brand-new session (no muxSession in its create config, _muxSession still null) the resolve-and-pin side effect ran and poisoned this._ompConfig before that field was even read. Fix: gate the resolve-and-pin logic on `this._muxSession` already being set. A fresh session has no muxSession yet and now passes through untouched; a real reattach (muxSession present since construction) keeps resolving and pinning exactly as before. Verified live in production against the exact reported scenario (a fresh omp session in a case dir with 8+ hours of prior omp history) - confirmed both via the API (ompConfig stays empty, claudeSessionId equals the session's own id) and visually in the GUI. Regression test constructs a real Session + TmuxManager to exercise the actual private-method interaction directly, since no existing test called startInteractive() at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Sonnet 5
parent
1829fe91af
commit
ab83d8ffec
@@ -1674,6 +1674,19 @@ export class Session extends EventEmitter {
|
||||
private _resolvedOmpRespawnConfig(): OmpConfig | undefined {
|
||||
if (this.mode !== 'omp') return this._ompConfig;
|
||||
if (this._ompConfig?.resumeSessionId) return this._ompConfig;
|
||||
// Resolving-and-pinning is only correct when a mux session ALREADY exists for
|
||||
// this Session object — a dead-pane respawn, or a boot-recovery reattach (the
|
||||
// constructor sets _muxSession from persisted state before startInteractive()
|
||||
// ever runs there). A genuinely brand-new session (Run OMP -> POST
|
||||
// /api/quick-start -> a fresh Session with no muxSession in its create config)
|
||||
// has _muxSession still null at this point. Without this guard, the eager
|
||||
// `respawnPaneOptions: this._buildRespawnPaneOptions()` in startInteractive()
|
||||
// mutates this._ompConfig via the side effect below BEFORE
|
||||
// createSessionOptions.ompConfig is even read in the SAME object literal, so a
|
||||
// fresh "Run OMP" click silently inherited whatever omp conversation happened
|
||||
// to be newest on disk for this working directory instead of starting clean
|
||||
// (reported live 2026-08-27).
|
||||
if (!this._muxSession) return this._ompConfig;
|
||||
const resolvedId = findLatestOmpSessionId(this.workingDir);
|
||||
if (resolvedId) {
|
||||
this._ompConfig = { ...this._ompConfig, resumeSessionId: resolvedId };
|
||||
|
||||
Reference in New Issue
Block a user