| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The test assumed that all pending write callbacks would run within two event loop iterations after the stream closed. Callbacks for writes already handed to the socket can run later, causing a flaky assertion. Wait for the stream to close and all expected write callbacks to run before closing the server. Signed-off-by: Kamat, Trivikram <16024985+trivikr@users.noreply.github.com> Assisted-by: codex:gpt-5.6-sol
|
Stress tests on |
Sorry, something went wrong.
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #64730 +/- ##
==========================================
- Coverage 90.15% 90.14% -0.01%
==========================================
Files 743 743
Lines 242407 242407
Branches 45645 45659 +14
==========================================
- Hits 218532 218527 -5
- Misses 15357 15384 +27
+ Partials 8518 8496 -22 see 35 files with indirect coverage changes 🚀 New features to boost your workflow:
|
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM. I specifically checked the removal of the explicit writeCbCount assertion: common.mustCall(..., N_WRITES) and the maybeCloseServer() gate preserve the exact-count invariant, so this removes the timing assumption without weakening the test coverage.
Sorry, something went wrong.
Sorry, something went wrong.
|
#63249 was marked semver-major, so adding dont-land labels here |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Refs: https://github.com/nodejs/reliability/issues?q=sort%3Aupdated-desc%20test-http2-reset-happy-close
The test previously expected all pending write callbacks to run within two
setImmediate() turns after the HTTP/2 stream emitted 'close'. Write
callbacks can run later when data has already been handed to the socket,
making that timing assumption unreliable under CI load.
Track stream closure and write callback completion independently, and close
the server only after both conditions are satisfied. Use common.mustCall()
to continue verifying that all 16 callbacks run. If a callback is genuinely
lost, the test harness will time out or report the callback count mismatch.
Assisted-by: codex:gpt-5.6-sol