-
Notifications
You must be signed in to change notification settings - Fork 16
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
feat: Enable Copilot by default if available #1037
Conversation
A couple of things we talked about this morning:
One more thing I was just thinking about: what is this experience like on Windows? If we're hosting a proxy to the VSCode LM API, do Windows users need to accept access to the network? At what point does this appear? We may need to set expectations with the user. |
I was able to get into the following state, but I don't have a lead on how this occurred just yet:
|
Is it possible that somehow the chat completion server got bound to IPv4 but the client resolves localhost to IPv6? I'm not sure how that might happen, they both use |
src/services/chatCompletion.ts
Outdated
@@ -44,7 +45,7 @@ export default class ChatCompletion implements Disposable { | |||
res.end(isNativeError(e) && e.message); | |||
} | |||
}); | |||
this.server.listen(portNumber); | |||
this.server.listen(portNumber, 'localhost'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we hard code to bind to 127.0.0.1
here? I have a scenario where this resolves to IPv4 and the client resolves localhost
to IPv6. I can't imagine we'd have any compatibility issues?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
afaik binding to 127.0.0.1 is pretty standard
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought about this, but then we have to change the client code to call 127.0.0.1 across the board and it will be broken with the mismatch. Here calling would be fine (because we're passing the URL to the CLI) but components have special casing for localhost for the backend display (so it won't say "(via copilot)" as is).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For RPC it will be a bigger issue I imagine, since we only pass the port number to the UI to connect to the server IIRC.
@dustinbyrne out of curiosity, what's the scenario? Is it something that we expect to be common? I had another solution in mind: a shadow server that would (try to) bind to the other localhost. I expect this will be fairly simple to implement. (Obviously we'll have to do the same thing for RPC.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This happened to both Kevin and I, and we're on different operating systems, so it seems like it could be fairly common. I don't think the UI is even a consideration here as the Copilot proxy is only used as the OPENAI_BASE_URL
.
I've added this commit to the branch which integrates the front end, and it does seem to resolve the issue.
b7a12bb
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For RPC it will be a bigger issue I imagine, since we only pass the port number to the UI to connect to the server IIRC.
Ah, you mean the RPC also binding to localhost
. Surprisingly, I haven't seen any issue here as of yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This happened to both Kevin and I, and we're on different operating systems, so it seems like it could be fairly common. I don't think the UI is even a consideration here as the Copilot proxy is only used as the
OPENAI_BASE_URL
.
OPENAI_BASE_URL is used to display the backend: https://github.com/getappmap/appmap-js/blob/19ea34b4cf94b76e14a32b5a1587f3b88bcbde06/packages/components/src/components/chat-search/LlmConfiguration.vue#L121
But it actually does check for 127.0.0.1 as well, so it's fine. (I thought it only checked for localhost.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For RPC it will be a bigger issue I imagine, since we only pass the port number to the UI to connect to the server IIRC.
Ah, you mean the RPC also binding to
localhost
. Surprisingly, I haven't seen any issue here as of yet.
We should keep an eye out for that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dustinbyrne FYI, here's what I had in mind: getappmap/appmap-js#2075
437149e
to
0206b6e
Compare
It's only used locally anyway, although security-wise it shouldn't matter much since it needs an authorization key to use anyway. As such, this change is mainly in an effort to avoid tripping up Windows firewall dialog.
0206b6e
to
48cce02
Compare
src/services/rpcProcessService.ts
Outdated
shouldRestart = true; | ||
} | ||
|
||
if (shouldRestart) this.restart(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me this should be unnecessary and is covered by the onDidChangeConfiguration
callbacks (with the possible exception of changing the OpenAI API key).
src/services/processWatcher.ts
Outdated
@@ -169,6 +175,7 @@ export class ProcessWatcher implements vscode.Disposable { | |||
} | |||
|
|||
async restart(): Promise<void> { | |||
this._onRestart.fire(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this fire after restart?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can rename it onBeforeRestart
or something similar.
This change removes a global five second debounce on changes to `appMap.commandLineEnvironment`. However, this behavior is not ideal in settings where the configuration is changed programatically along with other configuration which also restarts the service. A 100ms grace period is added to ensure multiple programmatic changes to configuration can be submitted before the process is restarted without triggering a longer debounce timeout.
a707ab6
to
8e19488
Compare
🎉 This PR is included in version 0.131.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
Changes the default to true and changes the flow a bit (this is executed on initialization and on state change):
Note for all these messages are shown only once, unless the state change is caused by user action.
Other changes: