fix(test): stabilize flaky SpanLifeCycle custom endTime test - #2754
Merged
Hector Hernandez (hectorhdzg) merged 1 commit intoAug 12, 2026
Conversation
The "EndTime: custom endTime is respected" test used Date.now() as the custom span end time and asserted the recorded endTime round-tripped within 10ms. The span start time is derived from performance.timeOrigin + performance.now(), not Date.now(). On loaded/virtualized CI hosts (observed on the Windows build container, Node 20) the system wall clock can drift slightly behind the span's perf-based start time. When Date.now() lands before the span start, span.end() clamps the duration to zero and sets endTime === startTime, so the round-trip difference exceeds the 10ms tolerance and the test intermittently fails (763 tests, 1 failed). Derive the custom end time from the span's own startTime so the comparison stays within the same time domain the SDK uses internally. This guarantees end > start (no zero-duration clamping) and keeps the value in the epoch range for an exact millisToHrTime round-trip, making the assertion deterministic.
Copilot started reviewing on behalf of
Hector Hernandez (hectorhdzg)
August 12, 2026 22:17
View session
Contributor
There was a problem hiding this comment.
Pull request overview
This PR stabilizes a flaky unit test around custom span endTime handling by ensuring the test uses the same time domain as the SDK’s perf-based start time, avoiding intermittent failures caused by CI host wall-clock drift.
Changes:
- Derives the custom span end time from the span’s own
startTime(HrTime) instead ofDate.now(). - Adds explanatory comments documenting the CI drift scenario and why
Date.now()can cause zero-duration clamping.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Comment on lines
+580
to
+582
| const startTime = span?.startTime; | ||
| const startMs = startTime ? (startTime[0] * 1000 + startTime[1] / 1000000) : Date.now(); | ||
| const customEndTime = startMs + 1000; // 1 second after the span start |
Jackson Weber (JacksonWeber)
approved these changes
Aug 12, 2026
Jackson Weber (JacksonWeber)
left a comment
Jackson Weber (JacksonWeber)
left a comment
Contributor
There was a problem hiding this comment.
LGTM after copilot comment is resolved.
Hector Hernandez (hectorhdzg)
merged commit Aug 12, 2026
cae0327
into
microsoft:main
9 checks passed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The "EndTime: custom endTime is respected" test used Date.now() as the custom span end time and asserted the recorded endTime round-tripped within 10ms. The span start time is derived from performance.timeOrigin + performance.now(), not Date.now(). On loaded/virtualized CI hosts (observed on the Windows build container, Node 20) the system wall clock can drift slightly behind the span's perf-based start time. When Date.now() lands before the span start, span.end() clamps the duration to zero and sets endTime === startTime, so the round-trip difference exceeds the 10ms tolerance and the test intermittently fails (763 tests, 1 failed).
Derive the custom end time from the span's own startTime so the comparison stays within the same time domain the SDK uses internally. This guarantees end > start (no zero-duration clamping) and keeps the value in the epoch range for an exact millisToHrTime round-trip, making the assertion deterministic.