fix(test, frontend, v1.2): bound the workflow-snapshot render's cost under jsdom - #8054
Draft
github-actions[bot] wants to merge 1 commit into
Draft
Conversation
…jsdom (#7999) ### What changes were proposed in this PR? `report-generation.service.spec.ts` drives the real html2canvas, which clones the whole document rather than the element it is pointed at. The unit-test builder runs spec files with `isolate: false`, so one jsdom document is shared by every spec file in a worker and the clone drags in whatever DOM the files before it left behind. On the macOS runner that clone was measured at 12–37s against a 20s test timeout, failing `fails when the editor cannot be rendered` while ubuntu and windows passed on the same commit. Two changes, both test-only: - **`report-generation.service.spec.ts`** — the snapshot suite parks the document's existing body nodes for the duration of the file and restores them after, so the render's cost depends only on the DOM these tests build. It spans the file rather than each test because the renders outlive the tests that start them (visible in the failing log: clone #1 finished during test #3). - **`jsdom-svg-polyfill.ts`** — stops jsdom announcing `getComputedStyle(elt, pseudoElt)` and `scrollTo` on the virtual console, which vitest forwards to `console.error` as a full stack trace per call. The failing job carried 5,691 of them for six renders. Dropping `pseudoElt` changes no behaviour: jsdom complains and then ignores the argument, returning the element's own declaration either way. `scrollTo` has nothing to move — jsdom has no layout, and the one html2canvas reaches for belongs to the throwaway clone iframe, so it is neutered as each `contentWindow` is handed out. ### Any related issues, documentation, discussions? Closes #8001. This continues #7886 (closing #7887), which stopped the four image-inlining tests in this file waiting on the render. The flake moved to the two tests that still await one. Scope note for reviewers: this bounds the render's cost, it does not remove the dependency on a real render. The two remaining tests still await html2canvas, so a sufficiently loaded runner could in principle still be slow — just not by the two orders of magnitude measured here. Taking #7886's logic to its conclusion (no test in this file waiting on a real render) would need a stub html2canvas that survives `isolate: false`, which is a larger change to what those two tests cover; happy to do that instead if reviewers prefer it. Unrelated pre-existing noise left alone: a full run still emits ~827 jsdom `HTMLCanvasElement.prototype.getContext` traces from `JointUIService.getMeasureContext` (`joint-ui.service.ts:219`). Silencing it would change what `measureText` returns for the joint-ui specs, so it is out of scope here. ### How was this PR tested? `ng test --watch=false` on this branch (base `444fc58284`), four full runs: 201 files, 5131 passed / 1 skipped each time, no `Not implemented: window.getComputedStyle` traces. Clone time across the file's six renders was 79–353 ms on three warm runs; the test that was timing out renders in 85–114 ms. The first run on a cold checkout was slower — up to 3.9s for a clone — which is a reminder that machine load, not document size, is what is left. The effect of the console noise was measured directly by seeding the document with 500 nodes: clone time across the six renders went 18.8s → 13.1s with the polyfill change alone (~30%; the share is larger where console forwarding is slower, as on CI). `yarn --cwd frontend format:ci` is clean. I cannot demonstrate the macOS leg green from here — that needs CI on this branch. ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Opus 5 [1M context]) --------- (backported from commit 646e460) Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
Author
|
The cherry-pick conflicted and was committed with conflict markers. Resolve the conflicts on this branch, then mark this PR ready for review. Conflicting files:
|
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.
What changes were proposed in this PR?
Automated backport of #7999 to
release/v1.2.Source: 646e460 · automation run
Any related issues, documentation, discussions?
Backport of #7999. Originally linked #8001.
How was this PR tested?
Release-branch CI runs on this branch once the conflicts are resolved and this PR is marked ready for review.
Was this PR authored or co-authored using generative AI tooling?
No.