Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Jul 7, 2025

Problem

The trackDependency method was incorrectly treating the current time as the start time when no explicit time parameter 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:

  1. trackDependency is called after a dependency operation completes
  2. The caller provides the duration of the already-completed operation
  3. The current time should represent when the operation ended, not when it started

Solution

Updated the timing logic in src/shim/telemetryClient.ts to correctly interpret the current time:

Before (incorrect):

const startTime = telemetry.time || new Date();
const endTime = startTime.getTime() + telemetry.duration;

After (correct):

// For trackDependency, when time is not specified, treat current time as END time
// since this method is called after the dependency operation has completed
const endTime = telemetry.time ? telemetry.time.getTime() + telemetry.duration : Date.now();
const startTime = telemetry.time || new Date(endTime - telemetry.duration);

Behavior Changes

  • Without telemetry.time (new default): Current time = end time, start time = end time - duration
  • With telemetry.time (backward compatibility): Preserves existing behavior where provided time = start time

Testing

Added comprehensive tests to validate both scenarios:

  • trackDependency default timing - should treat current time as end time: Validates the fix
  • trackDependency with custom time - should respect provided start time: Ensures backward compatibility

All 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.com
    • Triggering command: node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency (dns block)
    • Triggering command: node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency default timing (dns block)
    • Triggering command: 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.com
    • Triggering command: node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency (dns block)
    • Triggering command: node /home/REDACTED/work/ApplicationInsights-node.js/ApplicationInsights-node.js/node_modules/.bin/mocha ./out/test/unitTests --recursive --grep trackDependency default timing (dns block)
    • Triggering command: 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.

Co-authored-by: JacksonWeber <47067795+JacksonWeber@users.noreply.github.com>
@JacksonWeber
Copy link
Contributor

Looks good, but please determine if any other telemetry types experience this same issue.

Copilot AI changed the title [WIP] Bug: Incorrect default start time in trackDependency leads to shifted bars in traces Fix trackDependency default timing to treat current time as end time Jul 7, 2025
Copilot AI requested a review from JacksonWeber July 7, 2025 16:43
@JacksonWeber
Copy link
Contributor

Looks good, but please determine if any other telemetry types experience this same issue.

@copilot please reply to the above

…ime not specified

Co-authored-by: JacksonWeber <47067795+JacksonWeber@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Jul 7, 2025

Looks good, but please determine if any other telemetry types experience this same issue.

@copilot please reply to the above

Yes, trackRequest had the exact same timing issue as trackDependency. Both methods were incorrectly treating the current time as start time when no explicit time parameter was provided.

I've fixed trackRequest with the same logic and added comprehensive tests. The issue was that both methods are typically called after an operation completes, so current time should be the end time, not the start time.

Other telemetry types investigated:

  • trackAvailability, trackPageView, trackTrace, trackException, trackEvent: These delegate to LogApi without explicit timing calculations
  • trackMetric: No timing logic involved

Fixed in commit 7f1c814.

@JacksonWeber JacksonWeber marked this pull request as ready for review July 7, 2025 16:51
@JacksonWeber JacksonWeber requested a review from hectorhdzg July 7, 2025 18:41
@hectorhdzg hectorhdzg merged commit b0a8c29 into main Jul 8, 2025
16 checks passed
@JacksonWeber JacksonWeber mentioned this pull request Jul 25, 2025
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.

Bug: Incorrect default start time in trackDependency leads to shifted bars in traces

4 participants