-
Notifications
You must be signed in to change notification settings - Fork 670
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] flytectl panics when wrong config path is passed #4891
Comments
🤖 Hey @debajyoti-truefoundry! Great to see you back. Hope you're doing well. Thank you for bringing this to our attention. The panic you're experiencing when a wrong config path is passed is likely due to the fact that the error is not properly handled in the To resolve this issue, you should add error handling after the func (r *RootOptions) initConfig(cmd *cobra.Command, _ []string) error {
r.configAccessor = viper.NewAccessor(config.Options{
StrictMode: true,
SearchPaths: []string{r.cfgFile},
})
rootCmd := cmd
for rootCmd.Parent() != nil {
rootCmd = rootCmd.Parent()
}
// persistent flags were initially bound to the root command so we must bind to the same command to avoid
r.configAccessor.InitializePflags(rootCmd.PersistentFlags())
err := r.configAccessor.UpdateConfig(context.TODO())
if err != nil {
// Return the error immediately if the config file is not found or is invalid
return errors.Wrap(err, "failed to update config")
}
return nil
} With this change, if a wrong config path is passed, the This solution is similar to the one used in a previously solved issue: [BUG] Can't create project from file in demo. Please let me know if this resolves your issue or if you need further assistance. Sources
|
#take |
I found that the root cause is our failure to return an error when the config file is missing. As a result, errors occur when certain commands require the config. I’d like to understand why we chose not to return an error for an empty or missing config file—is there a specific reason for this? |
Reverting #6100 for now as this is causing issues for users and in CI in a bunch of our repos (e.g. https://github.com/flyteorg/flytekit/actions/runs/12266004823/job/34223269731?pr=2995). This change went out in flytectl 0.9.3. I'm looking into how to remove that release once a new version containing the revert is published. |
Describe the bug
Expected behavior
It will not panic.
Additional context to reproduce
No response
Screenshots
No response
Are you sure this issue hasn't been raised already?
Have you read the Code of Conduct?
The text was updated successfully, but these errors were encountered: