Repository navigation
Conversation
`t3 connect status`, `link` and `publish` printed their next steps as bare `t3 connect link`, `t3 service status`, `t3 serve` and `t3 connect login`, and `t3 service status` and `install` printed bare `t3 service install`, `t3 update <version>` and `t3 up`. Run with `--base-dir <dir>`, each printed command then acted on the default home instead of <dir>, so following "Run `t3 service install`" installed a service for ~/.t3. A new `resolveHostCliHint` next to `resolveHostCliCommand` puts the caller's `--base-dir` first, as `t3 up` already does, and both commands build their hints through it. They also print the runner or launcher form when that is how the CLI ran. Without `--base-dir` and run as plain `t3`, the text is unchanged. Bug: t3 connect's next-step hints drop --base-dir Bug: t3 service's next-step hints drop --base-dir
ApprovabilityVerdict: Approved at Macroscope's review found this PR approvable — Connect and service command hints now preserve explicit --base-dir values and use the appropriate host launcher. The changes affect printed guidance only, reusing existing shell quoting without changing operational behavior or defaults. You can add or adjust custom eligibility rules. Learn more. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
Problem
t3 connect status|link|publish --base-dir <dir>andt3 service status|install --base-dir <dir>print next steps without--base-dir, such as "Runt3 connect linkto authorize and enable T3 Connect.", "Next: Runt3 service install." and "Runt3 upto choose how your other devices reach it." Copied as printed, each one acts on the default~/.t3home instead of<dir>: the first links the wrong environment, and the second installs a service that serves~/.t3.Change
apps/server/src/cli/invocation.tsgetsresolveHostCliHint(subcommand, baseDir, args)next toresolveHostCliCommand. It puts--base-dir <dir>first when the caller passed one, then any other arguments, which is the ordert3 upuses (#29684, #30480) and #31878 keeps. Both commands build their hints through it:t3 connect status: its three "Runt3 connect link" next steps, and the "t3 service status" line shown when no server answers the reachability check.formatCloudStatustakes the two resolved commands instead of hard-coding them.t3 connect link: "Start the server witht3 serve", which usedresolveCliCommand("serve")and so never carried arguments.t3 connect publish: "Runt3 connect loginfirst".t3 service status: the "not installed" and "repair it" next steps, and the "newer than this CLI" next step (t3 update --base-dir <dir> <version>, plus thet3 service installit names for--allow-downgrade).formatServiceStatustakes the resolved commands and stays a pure formatter.t3 service install: "Runt3 upto choose how your other devices reach it." after a first install.Like the
t3 upandt3 pairhints, these now also print the runner form (npx t3@… connect link) or this install's launcher when that is how the CLI ran. Run as plaint3with no--base-dir, the text is unchanged. Every command named takes--base-dir, andt3 updateaccepts it ahead of its version argument.Scope and approval
This is the follow-up #29684 ("t3 up's pairing hint keeps --base-dir") named and left out: "the hints in
t3 service/t3 connectare not changed". It is the same defect with the same fix, in printed hints only, with no contract, setting or other behaviour change. That makes it a small, focused fix for an obvious bug. #31878 does the same for the rest oft3 upandt3 status. The two PRs touch different lines ofinvocation.tsand merge cleanly.Not changed here:
t3 service protect".t3 service protectacts on the unit path the service manager reports, which does not depend on--base-dir, so the bare command is correct.t3 service protect's own messages and the deprecatedt3 service updatemessage. These describe follow-ups, not the next step to run.t3 connect unlinkandt3 connect logoutstill print a bare "Runt3 connect unlinkagain" or "runt3 connect loginand retry" fromdisconnectCloud, andwaitForReachabilityprints "runt3 service status, thent3 connect status". The first two print only when the relay can't be reached or you are signed out. Fixing them needs abaseDiroption ondisconnectCloudandwaitForReachability, plus new arguments at theirup.tscall sites, so they are left for a follow-up. No open PR covers them.Open PRs on these files:
formatCloudStatus, and its tests call it asformatCloudStatus(status, { json: true }). After this PR the second parameter is the resolved commands, so fix(server): show T3 Connect account mismatch in connect status and link #21919 needs a rebase that also fixes those calls to typecheck, not only a textual merge. ItsACCOUNT_MISMATCH_REMEDYalso hard-codes bare commands. fix(web,server): this machine's menu copies the MCP URL its tunnel serves #23737 also exportsformatCloudStatusand calls it the same way in its tests.t3 connect linkserve hint toresolveHostCliCommand("serve"), which gives a trivial textual conflict on that line.formatServiceStatus, next to a changed line.git merge-treemerges it cleanly with this branch.t3 service restarthandler and does not conflict.Verification
apps/server/src/cli/connect.test.tsgets oneit.effect.eachtable with two rows. They run the real CLI (makeCli) ast3 connect status --base-dir <tmp>andt3 connect publish --base-dir <tmp>against an empty temp home. That home is unauthorized, so status prints the "Runt3 connect link" next step and publish prints the "Runt3 connect loginfirst" hint.apps/server/src/cli/service.test.tsextends the existing install table ("install keeps $label off the local network only when it is new") to also check thet3 uphint. Its two rows that install a new service expect the hint with--base-dir, and the older-service row expects none. A new two-row table runst3 service status --base-dir <tmp>against the stubBootServicethe other rows use, once for a missing service and once for a newer one (999.0.0).Each expected command is
resolveHostCliCommand(<hint>, ["--base-dir", <tmp>, ...args]), aspair.test.tsdoes for its hints. The expected text therefore follows the platform's quoting, and the rows behave the same on Windows and on CI's Ubuntu.On
mainwith only the test commit,vp test run src/cli/connect.test.ts src/cli/service.test.tsfromapps/server:With the fix:
Tests 20 passed (20).I ran these rows again the way CI does, with two uncommitted test edits:
HostProcess.Platformset tolinuxand the tempbaseDirwritten with forward slashes. Onmainall six failed, expecting POSIX-quoted hints such as`t3 connect link --base-dir C:/Users/…`and`t3 update --base-dir C:/Us…`. With the fix all seven filtered rows passed, including the older-service row.Runtime transcript, from
apps/server, with an empty temp home. PlaceholderT3CODE_RELAY_URL,T3CODE_CLERK_PUBLISHABLE_KEYandT3CODE_CLERK_CLI_OAUTH_CLIENT_IDare set so that theconnectcommand is registered. Both commands read only the temp home's state, and nothing reaches the network:The quoting is PowerShell's because this ran on Windows.
vp run check:changed: format, lint, knip, graphql and typecheck pass. The test step passes for every changed file exceptinvocation.test.ts, where two cases fail ("requires the npm prefix's bin to point to the running package" and "proves the downloaded executable was started by a global npm launcher"). They fail the same way onmainon Windows:realPathreturns backslashes that the npm-global pattern doesn't match, so runner detection sees the test'sbunx-toolsfolder. Both cases use Linux paths, and CI runs on Ubuntu.Not checked:
t3 servicehints. The background service exists only on Linux with systemd and macOS with launchd, and on Windowst3 service statusprints "unavailable on this machine" before any hint. The rows above run the real command handlers with onlyBootServicestubbed.t3 connect linkserve hint and the status "t3 service status" line were not seen at runtime. The first needs a real T3 Connect sign-in in a browser, and the second a linked environment whose server is down.All of these go through the same
resolveHostCliHintcall as the tested hints.Bug: t3 connect's next-step hints drop --base-dir
Bug: t3 service's next-step hints drop --base-dir
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.