[myabc]

Ticket

No work package. Frontend test-output hygiene, following up on #24622.

What are you trying to accomplish?

Removes most of the remaining non-failure noise from npm run test so real warnings stand out:

• the "Running mixed versions is not supported" banner (vitest 4.1.11 vs @vitest/browser 4.1.10)
• 13 "Lit is in dev mode" notices, one per test realm
• 24 NG0953: Unexpected emit for destroyed OutputRef warnings from the autocompleter debounce spec
• 3 Vitest notices about an unmocked confirm() in the global edit-form changes tracker spec
• expected console.error output from two error-path specs (autocompleter lookup failure, activities polling)
• an NG0912 component ID collision in the sortable-lists directive spec

Together with #24622, the only warnings left are the useDispatch() deprecation and FullCalendar's unknown dayGridClassNames option, which get their own PRs.

What approach did you choose and why?

Each warning is handled where it comes from. There is no global console filter.

• Vitest versions: bumps @vitest/browser-playwright and @vitest/coverage-v8 to ^4.1.11. The lockfile change only dedupes nested @vitest/* copies.
• Lit: seeds globalThis.litIssuedWarnings in test-browser-polyfills.ts, which runs before any module imports Lit. Lit checks this set itself before warning. Both keys are needed because lit-html dedupes by code and @lit/reactive-element by the full message.
• NG0953: the emit comes from ng-select's dropdown panel. _measureDimensions retries through a Promise + requestAnimationFrame chain with no destroyed guard. Closing the select or flushing a frame before teardown did not stop it, so the spec reuses the file's existing scoped silenceDestroyedOutputWarning() stopgap. The helper's comment now names the actual cause and links the upstream report, NgDropdownPanelComponent emits update/scroll after destruction (NG0953) ng-select/ng-select#2869, which is still unfixed in 24.1.2.
• Error-path specs: the logged error is part of the behavior under test, so the specs spy on console.error and assert it was called with the error.
• confirm(): the specs relied on Vitest answering false. They now stub the declined prompt explicitly.
• NG0912: two host components had identical templates and no selector. The teardown host gets a selector.

AI involvement

Directed – I specified the requirements and AI implemented most of it; I validated via testing rather than a full line-by-line review.

Merge checklist

• Added/updated tests — test-only change apart from the dev-dependency bump
• Added/updated documentation in Lookbook (patterns, previews, etc) — n/a
• Tested major browsers (Chrome, Firefox, Edge, ...) — n/a

[Copilot]

🟢 Approval recommended

No unresolved blocking issues were identified.

Pull request overview

Updates frontend test setup and specs to reduce expected Vitest warning noise.

Changes:

• Aligns Vitest dependencies to 4.1.11.
• Handles Lit and teardown warnings in scoped test contexts.
• Makes expected errors, prompts, and fixture behavior explicit.

File summaries

File	Description
frontend/src/test-browser-polyfills.ts	Seeds Lit warning registry.
frontend/src/stimulus/controllers/dynamic/work-packages/activities-tab/polling.controller.spec.ts	Asserts expected polling errors.
frontend/src/app/shared/directives/sortable-lists/sortable-lists.directive.behavior.spec.ts	Prevents component ID collisions.
frontend/src/app/shared/components/fields/edit/services/global-edit-form-changes-tracker/global-edit-form-changes-tracker.service.spec.ts	Stubs confirmation prompts.
frontend/src/app/shared/components/autocompleter/op-autocompleter/op-autocompleter.spec.ts	Handles expected errors and warnings.
frontend/package.json	Updates Vitest dependencies.
frontend/package-lock.json	Updates and deduplicates Vitest packages.

Review details

Files not reviewed (1)

• frontend/package-lock.json: Generated file

• Files reviewed: 6/7 changed files
• Comments generated: 0
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Warning

Flaky specs

• rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]
• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]
• rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25361, linked for reference only):

- `rspec ./modules/wikis/spec/features/admin/internal_provider_spec.rb[1:1]`
- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`
- `rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #25361. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25361 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.

[github-actions]

Warning

This pull request does not link an OpenProject work package.

Please add a link to the work package in the description, or reference it in the
title in square brackets, e.g. [SLUG-123] My title here.

[github-actions]

Warning

Flaky specs

• rspec ./modules/team_planner/spec/features/query_handling_spec.rb[1:3:1:1]
• rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]
• rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]

🤖 Ask Copilot to investigate

Copy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer.

@copilot The following spec(s) are flaky in CI (first seen on PR #25361, linked for reference only):

- `rspec ./modules/team_planner/spec/features/query_handling_spec.rb[1:3:1:1]`
- `rspec ./spec/features/notifications/navigation_spec.rb[1:1:1]`
- `rspec ./spec/features/projects/creation_wizard/wizard_from_template_flow_spec.rb[1:1]`

Treat this as a standalone task, unrelated to PR #25361. Create a new branch from origin/dev and open a new pull request targeting dev — do not stack it on PR #25361 or reuse that branch.

Follow the playbook in docs/development/testing/handling-flaky-tests/README.md to find the root cause and fix the underlying race — do not skip, delete, or weaken the spec to make it pass; disabling is a last resort per the playbook, and only with a bug ticket. Verify the fix by running the spec(s) repeatedly (e.g. `script/bulk_run_rspec --run-count 10`).

If you cannot reproduce the flake or are not confident in a fix after reasonable investigation, do not fabricate a change or skip the spec to force CI green. Instead, leave the pull request in draft and document what you tried, the suspected cause, and any leads in its description, then assign @myabc to take over.

Once the fix is verified, title the PR after the spec(s) it fixes, and use the PR description to explain the root cause, how the change resolves it, and the before/after results. Label the PR `flaky-spec`, assign @myabc, and request a review from @myabc.
On every commit, set @myabc as the sole co-author with a `Co-authored-by:` trailer (use their GitHub no-reply email so it links to their account), so it is traceable who dispatched the fix.