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

fix: improve cancel logic in openAi model #14713

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

eneufeld
Copy link
Contributor

What it does

The cancel of a request was not working correctly. With the changes the cancelToken is better taken into account.

How to test

Try using the inline completion of the IDE AI Feature. This leads to a very slow responsiveness of the ui as the underlying language model was continuing creating responses.
With the fix this is not the case anymore for the OpenAI Model.

Follow-ups

Improve cancel handling of all other language models.

Breaking changes

  • This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

Reminder for reviewers

@sdirix sdirix self-requested a review January 10, 2025 12:59
Copy link
Member

@sdirix sdirix left a comment

Choose a reason for hiding this comment

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

I did not notice any performance issues with this PR.

However something in the cancel/error flow does not work properly yet. In case a cancel occurs, the console logs the error two times:

root ERROR Uncaught Exception: Error: Canceled
root ERROR Error: Canceled

I think we should:

  • check for cancel errors and not log them. Maybe leave a log message on the DEBUG log level
  • make sure the errors are caught and handled appropriately

At the moment, once the error occurs, the code completion progress message Calculating AI code completion... is shown forever with the progress never canceling. Likely because the error was not caught.

Edit: Maybe we can also implement a flow without throwing errors

The cancel of a request was not working correctly.
With the changes the cancelToken is better taken into account.
@eneufeld eneufeld force-pushed the fix/inline-completion-cancel branch from 2eed0cc to 914bc53 Compare January 13, 2025 11:46
Copy link
Member

@sdirix sdirix left a comment

Choose a reason for hiding this comment

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

Works fine! I only have one small suggestion for an edge case

Comment on lines +295 to +301
error(id: string, error: Error): void {
if (!this.streams.has(id)) {
throw new Error('Somehow we got a callback for a non existing stream!');
}
const streamState = this.streams.get(id)!;
streamState.reject?.(error);
}
Copy link
Member

Choose a reason for hiding this comment

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

In the send callback which is also called from the backend we construct the stream state if it does not exist yet. I would suggest to do the same here.

If the first feedback of a stream is an error it could happen that the error arrives here first before the corresponding stream state was created as we don't control the async flows in the backend. We don't want to throw an error in that case but just handle it like all the other cases too.

@@ -286,6 +292,14 @@ export class FrontendLanguageModelRegistryImpl
throw new Error(`Could not find a tool for ${toolId}!`);
}

error(id: string, error: Error): void {
Copy link
Member

Choose a reason for hiding this comment

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

please add the same comment here as for send and toolCall

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Waiting on author
Development

Successfully merging this pull request may close these issues.

2 participants