fix(cli): ensure --profile option displays correct profile name #2541
Conversation
The CLI was displaying "default" or the first profile instead of the actual profile being used when the --profile option was specified. This fix ensures consistent profile resolution and display throughout the whoami command. - Added profileToUse variable that correctly resolves the profile name - Use readAuthConfigCurrentProfileName() for default profile resolution - Ensure all messages display the same profile name consistently 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
|
WalkthroughMultiple CLI command files were updated to pass an optional profile argument to printInitialBanner and printStandloneInitialBanner. The initialBanner utility API was changed to accept an optional profileOption and forwards it to getProfileInfo, which now accepts profileOption. Most call sites only add the profile parameter without other behavioral changes. Separately, the deploy command's failDeploy handling added INSTALLING to the set of serverDeployment.status values treated like PENDING/DEPLOYING/BUILDING. No other public exports were added or removed. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Pre-merge checks and finishing touches❌ Failed checks (4 warnings)
✅ Passed checks (1 passed)
✨ Finishing touches
🧪 Generate unit tests
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🧰 Additional context used📓 Path-based instructions (1)**/*.{ts,tsx}📄 CodeRabbit inference engine (.github/copilot-instructions.md)
Files:
🧬 Code graph analysis (1)packages/cli-v3/src/commands/deploy.ts (1)
🔇 Additional comments (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
packages/cli-v3/src/commands/whoami.ts (2)
77-79: Harden profile resolution with safe fallback and trimreadAuthConfigCurrentProfileName may throw if the config file is missing/corrupt (e.g., first‑run, not logged in). Also trim CLI input. Suggest a safe, explicit fallback to "default".
- const profileToUse = options?.profile ?? readAuthConfigCurrentProfileName(); + // Resolve the effective profile once. Fall back safely if config is missing. + let profileToUse: string = options?.profile?.trim() ?? ""; + if (!profileToUse) { + try { + profileToUse = readAuthConfigCurrentProfileName(); + } catch { + profileToUse = "default"; + } + }Please verify whether getConfig/readAuthConfigCurrentProfileName can throw on a fresh install or missing config and that "default" is an acceptable fallback for your UX.
150-151: Optional: prefer authenticated profile if availableMinor: after a successful auth, consider showing authentication.profile (canonicalized) if provided.
- `Account details [${profileToUse}]` + `Account details [${(authentication as any).profile ?? profileToUse}]`If LoginResult already narrows post early-return, you can type it without the cast.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
packages/cli-v3/src/commands/whoami.ts(5 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx}
📄 CodeRabbit inference engine (.github/copilot-instructions.md)
**/*.{ts,tsx}: Always prefer using isomorphic code like fetch, ReadableStream, etc. instead of Node.js specific code
For TypeScript, we usually use types over interfaces
Avoid enums
No default exports, use function declarations
Files:
packages/cli-v3/src/commands/whoami.ts
🧬 Code graph analysis (1)
packages/cli-v3/src/commands/whoami.ts (2)
packages/cli-v3/src/utilities/configFiles.ts (1)
readAuthConfigCurrentProfileName(79-82)packages/cli-v3/src/utilities/session.ts (1)
isLoggedIn(32-73)
🔇 Additional comments (4)
packages/cli-v3/src/commands/whoami.ts (4)
19-19: LGTM: correct importImporting readAuthConfigCurrentProfileName here is appropriate and aligns with the PR goal.
80-80: LGTM: consistent intro messagingIntro now reflects the resolved profile consistently.
107-107: LGTM: auth check uses the resolved profilePassing profileToUse to isLoggedIn aligns behavior and messaging.
116-121: LGTM: error hints reference the actual profileLogout/login guidance now correctly includes the resolved profile.
Address CodeRabbit review feedback: - Use logical OR (||) instead of nullish coalescing (??) to handle empty strings - Trim profile input to handle accidental whitespace from CLI This ensures more robust profile resolution when users provide input with accidental leading/trailing spaces. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Explains how profile resolution works: - No --profile: uses Zod default (readAuthConfigCurrentProfileName) - With --profile: trims whitespace, falls back to current if empty - Current profile defaults to 'default' when no config exists
- Rely on Zod schema default (readAuthConfigCurrentProfileName) for --profile fallback - Use consistent 'default' fallback pattern like other commands - Remove redundant readAuthConfigCurrentProfileName call - Maintain whitespace trimming for user input robustness
There was a problem hiding this comment.
Thanks for this @hongkongkiwi - sadly this tries to "fix" the output of the whoami command which was working fine before with --profile <name>. What we need to do is fix the header instead that is used for all commands.
According to @nicktrn's review: - Reverted unnecessary changes to whoami command (it was already working correctly) - Fixed the actual issue: header display in printInitialBanner() and printStandloneInitialBanner() - Now all commands pass their --profile option to the banner functions - Banner functions now correctly display the profile specified via --profile option This ensures the CLI header consistently shows the profile being used, whether it's the default or specified via --profile flag.
hongkongkiwi
force-pushed
the
fix/profile-display-consistency
branch
from
cb1d4d8 to
74c8741
Compare
Added profile parameter to printStandloneInitialBanner calls in: - workers/build.ts - workers/run.ts - workers/list.ts - workers/create.ts This ensures worker commands also display the correct profile in their headers when using --profile option.
|
Thanks @nicktrn . Does this fix the actual issue now? |
|
|
||
| switch (serverDeployment.status) { | ||
| case "PENDING": | ||
| case "INSTALLING": |
There was a problem hiding this comment.
this is interesting @myftija
Looks like it might, have you tested it? 😉 |
There was a problem hiding this comment.
let's revert this file, no need for profile here
Summary
Fixes an issue where the CLI
--profileoption was displaying the wrong profile name in command output.Fixes #2542
Problem
When using
--profile myprofile, the CLI would still display "profile: personal" or "profile: default" in the command output instead of showing the actual profile being used. This created confusion as users couldn't tell if their specified profile was actually being used.Solution
profileToUsevariable that correctly resolves the profile name at the start of thewhoAmIfunctionreadAuthConfigCurrentProfileName()for proper default profile resolution when no--profileis specifiedChanges
Modified
packages/cli-v3/src/commands/whoami.ts:readAuthConfigCurrentProfileNamefromconfigFiles.jsprofileToUsevariable that resolves to either the specified profile or the current defaultprofileToUseconsistentlyTesting
The fix ensures correct profile display in all scenarios:
trigger.dev whoami- correctly shows the current profile from configtrigger.dev whoami --profile myprofile- correctly shows "myprofile"Related Issues
Fixes #2542 - CLI displays incorrect profile name when using --profile option