Fix trackDependency default timing to treat current time as end time #1445
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
The
trackDependencymethod was incorrectly treating the current time as the start time when no explicittimeparameter was provided. This caused dependency traces to appear shifted in Application Insights, showing dependencies as starting when they should have already ended.The issue occurred because:
trackDependencyis called after a dependency operation completesdurationof the already-completed operationSolution
Updated the timing logic in
src/shim/telemetryClient.tsto correctly interpret the current time:Before (incorrect):
After (correct):
Behavior Changes
telemetry.time(new default): Current time = end time, start time = end time - durationtelemetry.time(backward compatibility): Preserves existing behavior where provided time = start timeTesting
Added comprehensive tests to validate both scenarios:
trackDependency default timing - should treat current time as end time: Validates the fixtrackDependency with custom time - should respect provided start time: Ensures backward compatibilityAll existing tests continue to pass, confirming no breaking changes to other functionality.
Impact
Dependency traces will now display correctly in Application Insights without appearing shifted, providing accurate timing visualization for dependency operations.
Fixes #1444.
Warning
Firewall rules blocked me from connecting to one or more addresses
I tried to connect to the following addresses, but was blocked by firewall rules:
global.livediagnostics.monitor.azure.comnode /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency(dns block)node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency default timing(dns block)node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency.*timing(dns block)westus-0.in.applicationinsights.azure.comnode /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency(dns block)node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency default timing(dns block)node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency.*timing(dns block)If you need me to access, download, or install something from one of these locations, you can either:
💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.