[RCCA-9133] Clear error msg when using api key with no secret saved locally

[MuweiHe]

Checklist

1. [CRUCIAL] Is the change for CP or CCloud functionalities that are already live in prod?
   • yes: ok

What

User caught the error very vague when using an api-key with no locally saved secret: the key id being the error msg itself. This is because we used a wrapper in UseAPIKey that changed the error type, so it's no longer a TypedError and can't print out the UserFacingError.
Changed the content in Error() for this pr. Will do a follow up to discuss about all other typedErrors

References

Test & Review

[Brian Strauch (brianstrauch)]

Did you figure out why Error() is being called but UserFacingError() isn't?

[Brian Strauch (brianstrauch)]

We shouldn't need to change this line if the user-facing error can be displayed properly.

[MuweiHe]

because in

cli/internal/cmd/api-key/command_use.go

Line 46 in b636d67

return errors.NewWrapErrorWithSuggestions(err, errors.APIKeyUseFailedErrorMsg, fmt.Sprintf(errors.APIKeyUseFailedSuggestions, apiKey))

we changed the error type to errors.ErrorWithSuggestionsImpl and it's no longer a cli typed error.

[MuweiHe]

Or we can don't wrap any suggestion in command_use.go, and wrap it in UseApiKey and FetchApiKeyError.

[Brian Strauch (brianstrauch)]

1. I think the Error() and UserFacingError() functions are a bad pattern (due to this bug that started this incident). We should move the UserFacingError() into Error() and only show Error().
2. Sounds like we're trying to add suggestions twice in this codepath? Do we have support for that?

[MuweiHe]

#2 yes, the UserFacingError is already an error with a suggestion. it'll look like:

mhe@C02DV0KVMD6T cli % confluent api-key use 123 --resource lkc-1x00v
Error: no API secret for API key "123" of resource "lkc-1x00v" stored in local CLI state

Suggestions:
    Store the API secret with `confluent api-key store 123 --resource lkc-1x00v`.

So using those typed errors you're not expected to add more wrappers after returning them to the command RunE. I can look further into all use cases of those typed errors and we'll discuss if we want to 1: remove typed errors and just keep the suggestion wrappers; 2: remove extra wrappers to ensure the error is being returned as a CLITypedError. Let's fix this one for this week's release first

[Brian Strauch (brianstrauch)]

This fixes the bug, but we should likely do the same for the other custom errors, so we don't encounter a similar bug in the future. Can you open a ticket for that?