Repository navigation
Activating a folder with no minimal.toml can stop the box, and the code leaves three unconfirmed causes #3075
Description
Summary
A tester reported that activating a session in a folder with no minimal.toml (via an editor client wrapper, min-vscode) leaves the box stopped or unusable. Reading the code at 0.7.3 (d1091c4), min session activate never refuses a folder for lacking minimal.toml: it carries on and the daemon writes a default. So the report is credible, but the cause is unconfirmed: no error text was captured, and the code leaves three different candidates that would each print different text. Every path that can stop such a box is in this repo; no client repo needs a change (all five wrappers just call min session activate --no-prompt).
Evidence (code reading only, nothing reproduced)
Carry-on path: resolve_upload_root treats NotFound as Ok(dir) (crates/minimal/src/cmd/project.rs:119); check_project_hooks and activate_hook_budget tolerate a missing mfile (crates/minimal/src/loadouts.rs:358, 430). The daemon runs scaffold_mfile_if_missing before compose and propagates errors (crates/minimald/src/session.rs:2589-2590), writing the default at 6229-6241.
Candidate causes, each with different error text:
min dashat 0.7.3 hard-refuses any non-VCS folder:refusing to upload '...': not a repository root(crates/minimal-tui/src/rpc.rs:616-618). It keys on VCS, not onminimal.toml, so a non-git folder that has aminimal.tomlis refused too. Only applies if dash was used.mainreplaced this with a confirm prompt (crates/minimal/src/dash/render.rs:758, from #2114); not an ancestor of d1091c4.- The daemon scaffold has no fallback.
InitProjectdoesupdate_checkout(DEFAULT_PKGS)?then a full graph load (crates/op/src/project/init.rs:63,81);Manager::update_remotedoesrepo.fetch()?with no cached fallback once the remote is registered (crates/checkouts/src/lib.rs:438-458). Any failure kills activation withCannot start a session for <dir>: composing a session environment from that directory's project configuration failed ... cause: scaffolding a default mfile: .... A project with a pinned, already checked-outlocked_commitskips the fetch, so a no-toml folder can fail where another project works. Still fatal onmain(crates/minimald/src/box_actor/setup.rs:383). - Timeout. Scaffold and compose run inside one
ConfigureLoadoutRPC capped atRPC_TIMEOUT= 60s (crates/minimal-client/src/lib.rs:193; plainoneshot_rpcatcmd/session.rs:1468), while the checkouts lock may wait up to 600s (crates/checkouts/src/lib.rs:174-179). A cold cache or lock contention would surface asConfigureLoadout RPC failed. Unchanged onmain. Real durations cannot be determined from code.
A weaker, unproven possibility: the scaffold pins pkgs main HEAD, the revision least likely to be cached, so a local build could hit the hang in #3058. Nothing in the code shows that happened.
Ruled out: a --no-prompt approval abort (scaffolded stack build_env_vars are literals, which bypass the policy); the T103 baseline blocking the scaffold fetch (github.com is the built-in registry endpoint). With --no-prompt, a non-VCS no-toml folder skips the upload with a warning and starts an empty /workbench (cmd/session.rs:1394-1418), which a tester could read as broken though the box does start.
Related defects found while reading
- Misleading wording.
composition_failure_message(crates/minimal/src/cmd/mod.rs:1012, raised atcmd/session.rs:1504,1550) blames "that directory's project configuration" for a folder that has none. - Test gap. Under
cfg(test)/test-support,default_mfile_planreturns a canned file and skipsInitProject(crates/minimald/src/session.rs:6256), soconfigure_loadout_scaffolds_missing_mfile_into_compositionnever exercises the production scaffold. --no-promptignored by the offer.offer_mfile_scaffoldchecksglobal.no_inputand the stdin TTY but notargs.no_prompt(project.rs:71), somin-vscode openfrom a terminal still gets the prompt, and a host-side init failure aborts activation via?atproject.rs:97although the doc comment says "Purely an offer".
What should happen
- Get the missing facts from the tester: the exact error text, which client was used, and whether the folder was a git repo.
refusing to uploadpoints to candidate 1 (already gone onmain; 0.7 4C29 .3 would need a backport or a release note).scaffolding a default mfileor a 60sConfigureLoadouttimeout points to candidates 2/3, which are still live onmain. - Make a failed default scaffold non-fatal or give it a bounded, cached fallback, and give the scaffold its own deadline instead of sharing the 60s
ConfigureLoadoutbudget. - Reword the composition failure for a folder with no project configuration, and name the cause and the next step.
- Make
offer_mfile_scaffoldhonor--no-prompt, and make its failure non-fatal. - Cover the production scaffold path in a test.
Confidence
The premise (0.7.3 is meant to continue and write a default) is confirmed by reading code. The specific cause is unconfirmed. Limits: checked at d1091c4 on a branch without an rc1 tag, so rc1 may differ; no existing issue found by searching for either error string.
Activity