test(debugger): fix flaky time budget integration test#7103
Conversation
Adds unit tests with mocked time for the debugger snapshot collector deadline mechanism and removes strict timing assertions from the flaky 1ms budget integration test. The integration test was failing in CI due to unpredictable execution times in GitHub Actions environments. The test set a 1ms capture timeout and expected thread pause time ≤16ms, which was too tight for resource-constrained CI environments.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #7103 +/- ##
==========================================
- Coverage 84.78% 84.77% -0.01%
==========================================
Files 521 521
Lines 22149 22149
==========================================
- Hits 18778 18776 -2
- Misses 3371 3373 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Overall package sizeSelf size: 3.59 MB Dependency sizes| name | version | self size | total size | |------|---------|-----------|------------| | import-in-the-middle | 1.15.0 | 127.66 kB | 856.24 kB | | dc-polyfill | 0.1.10 | 26.73 kB | 26.73 kB |🤖 This report was automatically generated by heaviest-objects-in-the-universe |
BridgeAR
left a comment
There was a problem hiding this comment.
LGTM, while I would use the other mock
| }) | ||
|
|
||
| it('should not mark properties with timeout when deadline is not exceeded', async function () { | ||
| process.hrtime = /** @type {any} */ ({ bigint: () => 0n }) |
There was a problem hiding this comment.
It is possible to also mock this with sinon: sinon.useFakeTimers()
There was a problem hiding this comment.
I did consider it, but didn't think it was worth while. I just pushed a commit with your suggestion, but I'm not sure the code is that much better. Maybe it's slightly worse depending on how you look at it. Let me know if you prefer it or if I should revert the last commit
|
Adds unit tests with mocked time for the debugger snapshot collector deadline mechanism and removes strict timing assertions from the flaky 1ms budget integration test. The integration test was failing in CI due to unpredictable execution times in GitHub Actions environments. The test set a 1ms capture timeout and expected thread pause time ≤16ms, which was too tight for resource-constrained CI environments.
Adds unit tests with mocked time for the debugger snapshot collector deadline mechanism and removes strict timing assertions from the flaky 1ms budget integration test. The integration test was failing in CI due to unpredictable execution times in GitHub Actions environments. The test set a 1ms capture timeout and expected thread pause time ≤16ms, which was too tight for resource-constrained CI environments.
Adds unit tests with mocked time for the debugger snapshot collector deadline mechanism and removes strict timing assertions from the flaky 1ms budget integration test. The integration test was failing in CI due to unpredictable execution times in GitHub Actions environments. The test set a 1ms capture timeout and expected thread pause time ≤16ms, which was too tight for resource-constrained CI environments.

What does this PR do?
Fixes a flaky integration test for the debugger's time budget mechanism by adding dedicated unit tests with mocked time and removing strict timing assertions from the integration test.
The changes add a new unit test file (
collector-deadline.spec.js) that uses mockedprocess.hrtime.bigint()to deterministically test the deadline checking logic in the snapshot collector. The problematic 1ms budget integration test now only validates behavioral outcomes (that timeout markers appear in snapshots) without asserting on exact execution time, which was causing CI failures.Motivation
The
snapshot-time-budget.spec.jsintegration test was flaky in GitHub Actions CI environments. The test set a 1ms capture timeout and expected the thread to be paused for ≤16ms (1ms + 15ms tolerance). This assertion frequently failed in CI due to:The flakiness was affecting CI reliability while not providing meaningful test coverage - the important behavior is that timeout markers appear, not the exact pause duration. By adding unit tests with mocked time for the actual deadline logic and relaxing the integration test to only check behavioral outcomes, we maintain full test coverage while eliminating CI flakiness.