[gjulivan]

Pull request type

---

Description

[github-actions]

AI Code Review

⚠️ Approved with suggestions — low-severity items only, safe to merge

---

What was reviewed

File	Change
packages/pluggableWidgets/combobox-web/e2e/Combobox.spec.js	Added maxDiffPixels: 10 tolerance to two toHaveScreenshot assertions
packages/pluggableWidgets/combobox-web/e2e/OnChange.spec.js	Replaced direct getLogs call with expect.poll retry loop for multi-assoc onChange test

Skipped (out of scope): dist/, pnpm-lock.yaml

---

Findings

⚠️ Low — Other screenshot assertions in the same file lack the same pixel tolerance

File: packages/pluggableWidgets/combobox-web/e2e/Combobox.spec.js (several assertions across the file)
Note: The two patched assertions now have { maxDiffPixels: 10 }, but visually similar assertions elsewhere (e.g. comboBoxAssociationOpen.png, comboBoxEnumOpen.png, etc.) do not. If the root cause is sub-pixel rendering flakiness, those tests could start failing too. Consider whether a shared options constant would be cleaner, or document in a comment why only these two needed the tolerance.

---

⚠️ Low — getLogs in non-polled tests still relies on waitFrames for timing

File: packages/pluggableWidgets/combobox-web/e2e/OnChange.spec.js lines 18–19, 34–35, 50–51, 87–88, 103–104
Note: The sibling boolean, enum, single assoc, database options over string, and static options over string tests still call getLogs (which internally calls waitFrames) directly and then assert synchronously. If the same timing issue that triggered this fix can affect multi-assoc, it could also affect those tests. Consider wrapping those assertions in expect.poll as well, or confirm the issue is specific to multi-assoc (e.g. due to two sequential selections firing events asynchronously).

---

Positives

• The switch from direct assertion to expect.poll for multi-assoc is the correct Playwright pattern — it retries until the condition is met rather than racing against Mendix's async commit, without introducing any hardcoded sleep or waitForTimeout.
• The ?.multiAssocTitles optional chaining on the poll return value correctly handles the case where the log entry hasn't arrived yet, preventing a runtime error on intermediate polls.
• Both changed files correctly import from @mendix/run-e2e/fixtures and use waitForMendixApp — no guideline violations introduced.