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

aichat: replace retry action on rate-limit prompt #22695

Merged
merged 2 commits into from Apr 3, 2024

Conversation

nullhook
Copy link
Contributor

@nullhook nullhook commented Mar 20, 2024

Resolves brave/brave-browser#36235

This PR replaces the redundant 'Retry' action, which appears when a user hits a rate limit error, with 'Maybe Later.' This new action dismisses the prompt and returns the failed message to the input box.

Submitter Checklist:

  • I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
  • There is a ticket for my issue
  • Used Github auto-closing keywords in the PR description above
  • Wrote a good PR/commit description
  • Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
  • Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
  • Checked the PR locally:
    • npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
    • npm run presubmit wiki, npm run gn_check, npm run tslint
  • Ran git rebase master (if needed)

Reviewer Checklist:

  • A security review is not needed, or a link to one is included in the PR description
  • New files have MPL-2.0 license header
  • Adequate test coverage exists to prevent regressions
  • Major classes, functions and non-trivial code blocks are well-commented
  • Changes in component dependencies are properly reflected in gn
  • Code follows the style guide
  • Test plan is specified in PR before merging

After-merge Checklist:

Test Plan:

@nullhook nullhook requested a review from a team as a code owner March 20, 2024 18:50
@github-actions github-actions bot added the CI/storybook-url Deploy storybook and provide a unique URL for each build label Mar 20, 2024
@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

Copy link
Collaborator

@mkarolin mkarolin left a comment

Choose a reason for hiding this comment

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

strings++

@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

Comment on lines +608 to +609
mojom::ConversationTurnPtr turn = chat_history_.back().Clone();
chat_history_.pop_back();
Copy link
Member

Choose a reason for hiding this comment

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

instead of cloning, can't we just move the entry, since we're getting rid of it anyway?

Copy link
Contributor Author

@nullhook nullhook Mar 26, 2024

Choose a reason for hiding this comment

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

yes, you can, but before sending it to the IPC, you'd have to convert it into a mojo::StructPtr<T> so, there's no point in returning a move-only value here because we will end up cloning anyways.

most mojo bindings code expects to deal with MyStructPtr version and i think it was a rookie mistake from my side to use MyStruct version for the history vector. i.e std::vector<mojom::ConversationTurn> chat_history_;

Copy link
Contributor Author

Choose a reason for hiding this comment

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

note to self: put a todo

Copy link
Member

Choose a reason for hiding this comment

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

ok, let's put a TODO in the header file for the vector class member

Copy link
Contributor Author

@nullhook nullhook Mar 28, 2024

Choose a reason for hiding this comment

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

added TODO

@@ -183,6 +183,7 @@ interface PageHandler {
ClearConversationHistory();
RetryAPIRequest();
GetAPIResponseError() => (APIError error);
ClearErrorAndGetFailedMessage() => (ConversationTurn turn);
Copy link
Member

Choose a reason for hiding this comment

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

need comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

added comment

Copy link
Member

Choose a reason for hiding this comment

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

...and removes it from the history... (not clear from the function name)

@@ -205,7 +208,7 @@ function Main() {
<PageContextToggle />
</div>
)}
<InputBox />
<InputBox inputText={failedInputText} />
Copy link
Member

Choose a reason for hiding this comment

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

The ergonomics of both this inputText prop and the onFailed function prop doesn't seem quite right to me. The behavior is not consistent with how we would normally expect a prop with the name "inputText" to be handled. How about we move the current input text state from InputBox to the context, and handle the submission to the conversation there, as well as the resetting of the input text when it fails. So that we have all that logic in the context instead of in the UI coimponents?

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 did think about lifting the inputText state to the context, but since it's a high-frequency updated value, the whole context tree would re-render and can lead to side effects. the current approach in the PR takes the minimal route because of that. now, you'd say i could create a whole new context for input-related states, and i'd tell you 'maybe,' but then, is it worth adding another layer when this is used only for one specific scenario? also, redux shouldn't be the answer.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok, so there will be upcoming use cases where we will need to control the inputText therefore i have lifted the state to context.

@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

@@ -213,6 +214,7 @@ class ConversationDriver {

// TODO(nullhook): Abstract the data model
std::string model_key_;
// TODO(nullhook): Change this to mojo::StructPtr
Copy link
Member

Choose a reason for hiding this comment

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

nit: mojo = mojom

Copy link
Contributor Author

@nullhook nullhook Apr 2, 2024

Choose a reason for hiding this comment

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

there's no such thing as mojom::StructPtr. its part of the mojo namespace. actually, the right notation should be: "Change this to mojo::StructPtr<T>"

Comment on lines 40 to 43
const handleMaybeLater = () => {
getPageHandlerInstance().pageHandler.clearErrorAndGetFailedMessage()
.then((res) => { context.setInputText(res.turn.text) })
}
Copy link
Member

@petemill petemill Apr 2, 2024

Choose a reason for hiding this comment

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

probably best that all this logic is contained in the context (via a function), no? In my mind, that was the advantage of moving the state up to the context...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

moved to context

if (isCharLimitExceeded) return
if (context.shouldDisableUserInput) return

getPageHandlerInstance().pageHandler.submitHumanConversationEntry(inputText)
setInputText('')
getPageHandlerInstance().pageHandler.submitHumanConversationEntry(context.inputText)
Copy link
Member

Choose a reason for hiding this comment

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

we should probably also move these calls to the context, shouldn't we?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

moved to context

@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

@nullhook nullhook requested a review from petemill April 2, 2024 18:30
@brave-builds
Copy link
Collaborator

A Storybook has been deployed to preview UI for the latest push

@nullhook nullhook merged commit 1483bbb into master Apr 3, 2024
19 checks passed
@nullhook nullhook deleted the aichat-ratelimit-dialog branch April 3, 2024 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CI/storybook-url Deploy storybook and provide a unique URL for each build
Projects
None yet
4 participants