Skip to content
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

chore: show human readable errors for toggle flag and fetch environment #170

Merged
merged 23 commits into from
Apr 18, 2024

Conversation

sunnyguduru
Copy link
Contributor

@sunnyguduru sunnyguduru commented Apr 11, 2024

CleanShot 2024-04-16 at 15 47 52

internal/quickstart/toggle_flag.go Outdated Show resolved Hide resolved
internal/quickstart/messages.go Outdated Show resolved Hide resolved
internal/quickstart/messages.go Outdated Show resolved Hide resolved
@sunnyguduru
Copy link
Contributor Author

gif added to description

Copy link
Contributor

@dbolson dbolson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think something like this setup will be simpler so we don't need to pass a boolean flag in the message.

@@ -117,6 +136,7 @@ func createFlag(client flags.Client, accessToken, baseUri, flagName, flagKey, pr
),
}
}
existingFlag = true
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized that with the recent changes #179 we were now forgetting to set existingFlag when there is a createFlag conflict

@@ -94,6 +97,9 @@ func (m toggleFlagModel) View() string {

if m.flagWasEnabled {
furtherInstructions = fmt.Sprintf("\n\nCheck your %s to see the change!", logTypeMap[m.sdkKind])
if m.alreadyEnabled {
furtherInstructions = "\n\nFlag was toggled too quickly."
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed toggle state. Also followed the example from line 70 Error toggling flag: you have toggled too quickly.

@@ -25,10 +25,14 @@ func sendErrMsg(err error) tea.Cmd {
}
}

type toggledFlagMsg struct{}
type toggledFlagMsg struct {
alreadyEnabled bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure this is more clear than passing an error and letting the model handle it. The createFlag command decides a particular error response isn't an actual error while the toggleFlag command always returns an error.

If the toggleFlag command returns either success (toggledFlagMsg) or failure (errMsg), then the model can decide how to show the error message instead of whether it's an error or not like the createFlag command.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's fair. I'll update to follow that format

return errMsg{err: err}
}

if !msgRequestErr.IsConflict() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can get a conflict error when fetching the environment, so we're probably fine to just return the error every time.

return errMsg{err: err}
}

if !msgRequestErr.IsConflict() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need this since we're checking for this in the model.

Copy link
Contributor

@dbolson dbolson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I get this message when I try to use "new" for the flag name:

invalid character 'E' looking for beginning of value

I also see "Error toggling flag: you have toggled too quickly" occasionally in addition to "Flag was toggled too quickly." Can you manually check these fixes?

@sunnyguduru
Copy link
Contributor Author

I get this message when I try to use "new" for the flag name:

invalid character 'E' looking for beginning of value

I also see "Error toggling flag: you have toggled too quickly" occasionally in addition to "Flag was toggled too quickly." Can you manually check these fixes?

Yeah, I can look into that. Weird I didn't see the E error with Sunny test flag.

@sunnyguduru
Copy link
Contributor Author

I get this message when I try to use "new" for the flag name:

invalid character 'E' looking for beginning of value

I also see "Error toggling flag: you have toggled too quickly" occasionally in addition to "Flag was toggled too quickly." Can you manually check these fixes?

The first issue is related to footerView. Seems that we were originally displaying errors there. I think it seems valuable to continue to show errors through footer view. So I want to remove showing errors through the "further instructions" string

@sunnyguduru
Copy link
Contributor Author

I get this message when I try to use "new" for the flag name:

invalid character 'E' looking for beginning of value

I also see "Error toggling flag: you have toggled too quickly" occasionally in addition to "Flag was toggled too quickly." Can you manually check these fixes?

The first issue is related to footerView. Seems that we were originally displaying errors there. I think it seems valuable to continue to show errors through footer view. So I want to remove showing errors through the "further instructions" string

Although the spacing gets more confusing that way

Copy link
Contributor Author

@sunnyguduru sunnyguduru left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here's a gif of me testing the changes:

  • Errors show up correctly for create flag (as well as conflict)
  • Errors show up correctly for toggle flag
    CleanShot 2024-04-16 at 15 47 52

Comment on lines 102 to 104
if m.existingFlagUsed {
successMessage = fmt.Sprintf("Using existing flag %q for setup.", m.flag.name)
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This code path doesn't get run anymore as of PR #179

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like that's a bug. Can you add existingFlag = true in the createFlag command after checking if !msgRequestErr.IsConflict()? That would mean there is an error and it's a conflict error, so we want to set the variable to true.

@@ -122,7 +119,7 @@ func createFlag(client flags.Client, accessToken, baseUri, flagName, flagKey, pr
return createdFlagMsg{flag: flag{
key: flagKey,
name: flagName,
}, existingFlagUsed: existingFlag}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

exisitingFlagUsed wasn't getting used anymore so I removed references to it.

Comment on lines -95 to 97
if m.flagWasEnabled {
if m.flagWasEnabled && m.err == nil {
furtherInstructions = fmt.Sprintf("\n\nCheck your %s to see the change!", logTypeMap[m.sdkKind])
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Prevent showing the success message when there is an error.

@sunnyguduru sunnyguduru merged commit 4e812c6 into main Apr 18, 2024
2 checks passed
@sunnyguduru sunnyguduru deleted the sunny/sc-239301/show-human-friendly-error-messages branch April 18, 2024 17:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants