Repository navigation
Conversation
roncodes
commented
May 23, 2023
roncodes
left a comment
roncodes
left a comment
Member
Author
There was a problem hiding this comment.
All looks good, but need to run tests from inside console, then bump version
roncodes
added a commit
that referenced
this pull request
Aug 25, 2026
…(DEFECTS #16) The cause, at last, and it is a known upstream bug rather than anything odd about this repo. sendCoverage() POSTs ~1.9 MB to /write-coverage — 401 instrumented files, because a per-file 100% gate needs forceModulesToBeLoaded() to evaluate everything so untested files stay in the denominator. In CI mode testem tears the browser down the moment QUnit reports the run finished, truncating the upload mid-body. raw-body aborts, coverageHandler is never reached, and nothing is written. That is why it looked like flakiness rather than a bug: it depends on how long the run took. After 139 tests testem has almost nothing to serialize and kills the browser in milliseconds; after 5130 tests, emitting the results buys the upload enough time to land. Measured 2 of 9 artifacts on fast filtered runs against 100% on full runs, with `BadRequestError: request aborted` correlating 1:1 with every failure. Testem.afterTests hands testem a callback it WAITS for, so the upload finishes before teardown. It does not fire under --server, hence the branch on config.APP.isRunningWithServerArgs. Upstream, all with the identical raw-body:245 stack: ember-cli-code-coverage#420 (Aug 2024), #421, testem#1577 Our measurements are added to #420. Measured: 2 of 2 fast filtered runs now produce an artifact with no abort. Full suite unchanged — 5130 pass, 0 fail, lint 0. Ruled out and recorded so nobody retries them: keepalive:true and sendBeacon (the Fetch spec caps both at 64 KiB, ~30x under our payload), and moving forceModulesToBeLoaded() to QUnit.begin (0 of 3, and against the guidance in the addon's own source, which says to call it after the suite). Also recorded a debugging trap: instrumenting coverageHandler shows nothing on a failing run, which reads as "the POST never arrived". It does arrive and dies inside bodyParser, before the handler. I drew the wrong conclusion from that and had to retract it; instrument in front of bodyParser, not behind it. The freshness gate from PR #163 stays. It is what made this failure loud instead of silent, and it is still the guard against reading a stale report. DEFECTS #18 opened: branch totals still vary by +/-1 between identical runs (5825 vs 5826 across three otherwise-identical full runs). Same class of gate blocker #4 was, culprit not yet located.
This was referenced Aug 25, 2026
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
1 participant
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.
No description provided.