Repository navigation
Conversation
…transcript The runner allocates a transcriptId for every run, but populationTool stays null when no selected Claude Code / Codex CLI was found. SetupPage gated the transcript panel on transcriptId alone, so a run that launched nothing rendered a finished, empty transcript beside the manual prompt. - require populationTool before rendering the wizard's transcript panel - add `unavailable` to SetupPopulationLaunchResult (agents probed and missing, in selection order) and use it to pick between "no selected tool can do this automatically" and "<tool> was not found on PATH for this process" - extend the tests that pin the launch result for the new field Closes mex-memory#269
Author
|
@theyashasvipandey @theDakshJaitly CI for this head (run 38045873943) has been waiting at |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Closes #269. Stops the setup wizard from showing a session transcript for a run that never launched an agent, and says why the manual prompt appeared instead of reusing the generic waiting message.
Why
Read at
main(54f7d7a5), the mechanism is exactly as #269 describes:src/hub/setup/runner.ts:238allocates atranscriptIdfor every run, andpopulationToolstartsnull(L248) and staysnullwhen no CLI is found.src/setup/population.tsreturned{ tool: null, completed: false }with no record of which agents were checked and missing.src/setup/headless.ts:284therefore always emitted "Setup is waiting for population…" whether or not anything had run.packages/hub-web/src/pages/SetupPage.tsx:275gated the panel ontranscriptIdalone, so an empty transcript appeared next to the manual prompt.Change
SetupPopulationLaunchResultgainsunavailable: SetupAgentTool[]— the agents that were probed and not found, in the user's selection order. Agents after the chosen one are never probed, so they are absent; an empty list withtool: nullmeans "no selected tool is one setup can drive", which is a different reason and now gets a different message.headless.tsselects between those two explanations, and keeps the existing waiting message when an agent really did run but did not finish.SetupPage.tsx:275also requirescurrentRun.populationTool.selectSetupAgentnow delegates to the shared picker, so the ordering rule lives in one place and each CLI is probed at most once.Deliberately not changed:
ProgressPanel(L602) still renders the transcript during the population step.populationToolis only set once the first activity record is parsed, so guarding there would blank the panel for an agent that is running. Easy to add if you disagree.How to test
Measured on Windows 11, node 24.21.0:
src/setupfilessetup-page.test.tsxnpm run typecheck(contracts + root + hub-web)npm run buildThe single remaining failure,
headless-population.test.ts:329(expect(onActivity).not.toHaveBeenCalled()), reproduces on cleanmainin the same file set — it is not from this diff. The right-hand column is the control that shows the new tests actually bite:hides the session transcript when setup launched no agent, and the twoheadlessmessage tests, all fail without the fix.Two things I want to flag rather than bury
1. This diff is not assertion-neutral. Eight
toEqual({ tool, completed })assertions inheadless-population.test.tspin the whole result object, so addingunavailabletook that file from 1 failure to 11. I only found it by running a base control over the same 15 files (Test Files 15 failed, identical per-file counts in 13/15) instead of assuming the red was pre-existing; two files differed, one of them was mine. Those 8 assertions are updated here.2. The full suite is broadly red on Windows with or without this change —
npm run testreports 21 of 298 files failing here (status.test.ts3,git-port.test.ts3,migrate.test.ts5, several*.contract.test.ts). Thecheckjob runs on ubuntu only, so CI is the real gate; I am not claiming a green local suite.jsdom limit
The new page test asserts the panel is absent for a run with
populationTool: null. It does not reproduce the reporter's exact "This session produced no output." string — that copy needs the transcript batch to reportdone, and the fixture can only deliver a batch once the panel has subscribed. Pre-fix, the same test shows the region rendering with "Waiting for session output…", which is the same defect (a panel for a session that never existed) at an earlier stream state.Checklist
npm run typecheckandnpm run buildrc=0 locallynpm testgreen locally — not true on Windows, see above; ubuntu CI is the gateAI-assisted (Qoder); every number above comes from commands run on this machine, and the diff was read line by line before pushing.