Repository navigation
fix: polish desktop development and workspace controls - #813
Conversation
Assisted-by: gpt-6.1-terra
[Medium impact] The changes affect local desktop development and a bounded set of workspace controls. Fix the single-run row before merging so a later run does not inherit a disabled Stop button. FindingsFix with agent prompt### Issue 1
ui/src/components/ExperimentRunBanner.tsx:56
If a cancelled run finishes and another run starts before the next refresh, the list can change directly from `[A]` to `[B]`. The single-run branch reuses the same `RunRow`, so B inherits A's `pending=true`. B then shows “Cancelling” with Stop disabled, even though nobody cancelled it.
Add `key={runs[0].run.id}` to reset the row when the run changes, as the multi-run branch already does.
```suggestion
if (runs.length === 1) return <div className={BANNER_CLASS}><RunRow key={runs[0].run.id} item={runs[0]} onOpenRun={onOpenRun} onOpenExperiment={onOpenExperiment} /></div>;
```
### Issue 2
scripts/dev-slot.mjs:720-730
With a running `copy` slot, `start --db empty --desktop` now kills the desktop app and stops both servers before `reserveSlot` rejects the database-mode mismatch. Previously, the rejected command left the running slot alone.
Check the requested mode before stopping the existing app and servers so a failed launch does not interrupt the developer's session.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.SummaryThis PR ties the development desktop app to its servers and polishes workspace controls.
|
|
|
||
| export function ExperimentRunBanner({ runs, onOpenRun, onOpenExperiment }: { runs: ChatActiveRun[]; onOpenRun?: OpenTarget; onOpenExperiment?: OpenTarget }) { | ||
| if (runs.length === 0) return null; | ||
| if (runs.length === 1) return <div className={BANNER_CLASS}><RunRow item={runs[0]} onOpenRun={onOpenRun} onOpenExperiment={onOpenExperiment} /></div>; |
There was a problem hiding this comment.
If a cancelled run finishes and another run starts before the next refresh, the list can change directly from [A] to [B]. The single-run branch reuses the same RunRow, so B inherits A's pending=true. B then shows “Cancelling” with Stop disabled, even though nobody cancelled it.
Add key={runs[0].run.id} to reset the row when the run changes, as the multi-run branch already does.
| if (runs.length === 1) return <div className={BANNER_CLASS}><RunRow item={runs[0]} onOpenRun={onOpenRun} onOpenExperiment={onOpenExperiment} /></div>; | |
| if (runs.length === 1) return <div className={BANNER_CLASS}><RunRow key={runs[0].run.id} item={runs[0]} onOpenRun={onOpenRun} onOpenExperiment={onOpenExperiment} /></div>; |
Prompt To Fix With AI
This is a comment left during a code review.
Path: ui/src/components/ExperimentRunBanner.tsx
Line: 56
Comment:
**Stop stays disabled**
If a cancelled run finishes and another run starts before the next refresh, the list can change directly from `[A]` to `[B]`. The single-run branch reuses the same `RunRow`, so B inherits A's `pending=true`. B then shows “Cancelling” with Stop disabled, even though nobody cancelled it.
Add `key={runs[0].run.id}` to reset the row when the run changes, as the multi-run branch already does.
```suggestion
if (runs.length === 1) return <div className={BANNER_CLASS}><RunRow key={runs[0].run.id} item={runs[0]} onOpenRun={onOpenRun} onOpenExperiment={onOpenExperiment} /></div>;
```
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.| const previous = reservationFor(info) | ||
| if (previous?.state?.desktopProcess && processGroupExists(previous.state.desktopProcess.pid)) { | ||
| if (!supervisorMatches(previous.state.desktopProcess)) throw new Error('The previous desktop process no longer matches its recorded identity') | ||
| process.kill(-previous.state.desktopProcess.pid, 'SIGTERM') | ||
| await waitFor('the previous desktop app to close', 10_000, () => !processGroupExists(previous.state.desktopProcess.pid)) | ||
| } | ||
| await stopOwnedProcessesUnlocked(info) | ||
| if (interrupted) return | ||
| const mode = requestedMode ?? previous?.state?.dbMode ?? 'empty' | ||
| started = true | ||
| await startUnlocked(info, mode, false) |
There was a problem hiding this comment.
Failed launch stops working session
With a running copy slot, start --db empty --desktop now kills the desktop app and stops both servers before reserveSlot rejects the database-mode mismatch. Previously, the rejected command left the running slot alone.
Check the requested mode before stopping the existing app and servers so a failed launch does not interrupt the developer's session.
Prompt To Fix With AI
This is a comment left during a code review.
Path: scripts/dev-slot.mjs
Line: 720-730
Comment:
**Failed launch stops working session**
With a running `copy` slot, `start --db empty --desktop` now kills the desktop app and stops both servers before `reserveSlot` rejects the database-mode mismatch. Previously, the rejected command left the running slot alone.
Check the requested mode before stopping the existing app and servers so a failed launch does not interrupt the developer's session.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
Assisted-by: gpt-6.1-terra
Tested manually