Skip to content

Add logging channel and more logging to chat agent handler #19398

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

lewis-sanchez
Copy link
Contributor

This PR fixes #19363

Copy link

PR Changes

Category Main Branch PR Branch Difference
Code Coverage 55.17% 54.73% .44 %
VSIX Size 15277 KB 15292 KB 15 K B   ( 0 % )
Webview Bundle Size 3656 KB 3656 KB 0 K B   ( 0 % )

let conversationUri = getNextConversationUri();
let connectionUri = vscodeWrapper.activeTextEditorUri;

Utils.logDebug(
logger.info("In handler");
Copy link
Contributor

Choose a reason for hiding this comment

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

This "entered/exited XYZ function" can probably be verbose- instead of info-level logging. Same for the other spots

Copy link
Member

@kburtram kburtram left a comment

Choose a reason for hiding this comment

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

Not sure if we need this? Verses logging to the primary extension output channel.

@@ -46,17 +47,24 @@ export const createSqlAgentRequestHandler = (
return () => `conversationUri${idCounter++}`;
})();

const getLogger = (() => {
Copy link
Member

Choose a reason for hiding this comment

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

Is it best practice to create a different logging channel per feature area? This seems like total over kill. I'd expect the extension to have 1 or 2, or maybe 3. But it seems like we're creating these for more smaller feature areas in recent PRs. Is there some guidance from the vscode team this is a good pattern to follow? I prefer to have my logs consolidated generally to be able to spot errors that cross subsystem boundaries (up to a point, or course)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Benjin, do you have additional info on why it was suggested to use a MssqlCopilot logger in addition to copilot specific messages being easier to filter?

Copy link
Contributor

Choose a reason for hiding this comment

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

This call reuses the same "MSSQL" output channel as the rest of the extension; the second parameter is a string tag that gets included in each message so that you can optionally filter your messages further by searching for [tag] in the MSSQL channel:

image

Should be easier to both view the full picture and isolate specific areas in the logs.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks! Prefix label on message in the main MSSQL channel makes sense to me.

@kburtram
Copy link
Member

My take on this PR is that we should probably send most the logging to a single channel, perhaps for very specific logging we might want to isolated it, but I don't think we should create a different logging channel for each feature area. Unless VS Code is recommending extensions do that.

@Benjin
Copy link
Contributor

Benjin commented May 22, 2025

@kburtram

Unless I'm misunderstanding, I think we're already doing that; everything's going to the MSSQL channel
image
image

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.

[GitHub Copilot - Bug]: Consider logging channel for copilot messages
3 participants