Remove redundant perf client and function wrapper logging #8079
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR removes redundant logging statements from performance client and function wrapper utilities to reduce noise in debug output. The changes focus on eliminating trace-level logging that provides minimal diagnostic value while maintaining error logging and telemetry functionality.
Key changes:
- Removed trace logging from function wrapper execution flow
- Eliminated verbose performance measurement logging from PerformanceClient
- Updated corresponding test expectations to match reduced logging calls
Reviewed Changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| lib/msal-common/src/utils/FunctionWrappers.ts | Removed trace logs for function execution start and successful completion |
| lib/msal-common/src/telemetry/performance/PerformanceClient.ts | Removed trace and info logs for measurement lifecycle events and field updates |
| lib/msal-common/test/utils/FunctionWrappers.spec.ts | Updated test to reflect reduced logger call count after removing trace statements |
| lib/msal-browser/src/controllers/StandardController.ts | Improved PKCE code logging message clarity (unrelated cleanup) |
Comments suppressed due to low confidence (1)
lib/msal-common/test/utils/FunctionWrappers.spec.ts:66
- The loggerSpy variable is removed but still used in the failure test case on line 94. This will cause a ReferenceError when the test runs.
const loggerSpy = jest.spyOn(logger, "trace");
konstantin-msft
force-pushed
the
remove_redundant_perf_client_logging
branch
from
a4351b4 to
6d71725
Compare
| correlationId: string | ||
| ) => { | ||
| return (...args: T): U => { | ||
| logger.trace(`Executing function '${eventName}'`, correlationId); |
There was a problem hiding this comment.
For customers not using the performance client how do these things get logged?
There was a problem hiding this comment.
This is not going to be logged at all.
There was a problem hiding this comment.
I think that's going to be a problem when we receive issues/ICMs from external customers not using the 1P lib
There was a problem hiding this comment.
This isn't going to be a problem for 3p customers unless they inject their own performanceClient.
There was a problem hiding this comment.
3P customers aren't using performanceClient at all, I think we need to leave these logs here for those scenarios
3 participants
Remove redundant perf client and function wrapper logging.
contexttelemetry field provides a func call tree so we don't need additional logging for that.