test(ci): probe K — Node 22 added to Windows-no-plugins matrix as comparator

[JohnMcLear]

Probe K from the silent-ELIFECYCLE flake matrix. After probe A (#7855) ruled out Defender and probe G (#7862) deploys ProcDump for forensic capture, this PR adds a parallel data point: run Win-no-plugins on Node 22 alongside the existing Node 24 job. If the flake rate drops materially on Node 22, we have a clear bisection target. If unchanged, Node version isn't the cause.

Adds engines-strict=false to .npmrc on the Node 22 job only (Etherpad's package.json has engines.node: >=24). Scoped to Win-no-plugins to minimise CI cost — the same probe on the with-plugins job adds ~5 minutes more per push because of plugin install.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[qodo-free-for-open-source-projects]

Review Summary by Qodo

Add Node 22 comparator to Windows-no-plugins CI matrix for flake bisection

🧪 Tests

Walkthroughs

Description

• Add Node 22 to Windows-no-plugins CI matrix as flake bisection probe
• Compare flake rates between Node 22 and Node 24 to identify root cause
• Relax engines-strict for Node 22 job to bypass package.json constraint
• Minimal CI cost impact by scoping to cheapest matrix variant

Diagram

flowchart LR
  A["Windows-no-plugins<br/>Node 24 baseline<br/>20-30% flake rate"] -->|"Compare flake rates"| B["Windows-no-plugins<br/>Node 22 comparator<br/>engines-strict=false"]
  B -->|"If flake drops to ~0"| C["Node 24 specific issue<br/>libuv IOCP regression"]
  B -->|"If flake unchanged"| D["Node version ruled out<br/>investigate other causes"]

Loading

File Changes

1. .github/workflows/backend-tests.yml 🧪 Tests +19/-2

Add Node 22 matrix entry with engines-strict override

• Expanded withoutpluginsWindows matrix to include Node 22 alongside existing Node 24
• Added conditional step to relax engines-strict for Node 22 job only
• Updated matrix comment to explain PROBE K bisection strategy and per-job override approach
• Appends both engine-strict=false and engines-strict=false to .npmrc for Node 22

.github/workflows/backend-tests.yml

---

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0)

1. Cache key ignores Node 🐞 Bug ☼ Reliability

Description

withoutpluginsWindows now runs a Node 22/24 matrix but still uses a pnpm-store cache key that does
not include matrix.node, so both Node versions will restore/save the same cache entry and can
cross-contaminate results (hurting the probe’s validity and potentially causing flaky
installs/tests).

Code

.github/workflows/backend-tests.yml[R182-187]

Evidence

The workflow change expands the Windows-no-plugins matrix to run Node 22 and 24, while the pnpm
store cache key in the same job does not include matrix.node, so both matrix entries will use the
same cache key.

.github/workflows/backend-tests.yml[173-201]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The Windows-without-plugins job now runs on both Node 22 and Node 24, but the pnpm store cache key does not vary by Node version. This means the Node 22 and Node 24 matrix entries can restore/save the same pnpm store cache, which can skew the comparator probe and introduce version-dependent flakiness.

### Issue Context
The matrix was expanded to `[22, 24]`, but the pnpm store cache key remains `${{ runner.os }}-pnpm-store-${{ hashFiles('**/pnpm-lock.yaml') }}`.

### Fix Focus Areas
- .github/workflows/backend-tests.yml[173-201]

### Suggested change
- Update the `actions/cache` key (and restore-keys) to include `matrix.node`, e.g.:
 - `key: ${{ runner.os }}-pnpm-store-node${{ matrix.node }}-${{ hashFiles('**/pnpm-lock.yaml') }}`
 - `restore-keys: ${{ runner.os }}-pnpm-store-node${{ matrix.node }}-`

(Optionally consider whether the separate `actions/cache` step is still needed given `actions/setup-node` already has `cache: pnpm`, but the minimum fix is to make the explicit cache key node-specific.)

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Engines override too broad 🐞 Bug ⚙ Maintainability

Description

The engines-strict relaxation step is documented as a Node 22-only comparator override, but its
condition is matrix.node != 24, so any future non-24 matrix value would unexpectedly run with
relaxed engine checks.

Code

.github/workflows/backend-tests.yml[R216-218]

Evidence

The step comment says it’s for the Node 22 comparator, but the condition is written as a negation of
24, making it apply to any non-24 entry.

.github/workflows/backend-tests.yml[210-223]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow intends to relax engine enforcement only for the Node 22 comparator run, but the step uses `if: matrix.node != 24`, which will apply to any Node version other than 24 if the matrix is expanded later.

### Issue Context
The step comment and naming indicate the override is specific to the Node 22 comparator.

### Fix Focus Areas
- .github/workflows/backend-tests.yml[210-223]

### Suggested change
- Change the condition to explicitly target Node 22:
 - `if: matrix.node == 22`
- (Optional) Update the step name/comment to match the final condition exactly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Redundant npmrc engine keys 🐞 Bug ⚙ Maintainability

Description

The Node 22 override appends both engine-strict=false and engines-strict=false to .npmrc,
creating redundant/ambiguous configuration that makes it harder to reason about what setting is
intended.

Code

.github/workflows/backend-tests.yml[R219-222]

Evidence

The workflow explicitly appends two different engine-strict-related keys to the existing checked-in
.npmrc, which already contains configuration entries.

.github/workflows/backend-tests.yml[219-222]
.npmrc[1-7]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The workflow appends two similarly named keys to `.npmrc` (`engine-strict` and `engines-strict`). Keeping only the intended key reduces ambiguity and makes debugging the probe setup simpler.

### Issue Context
The repo already has a checked-in `.npmrc`, and this step appends additional config lines for the Node 22 job.

### Fix Focus Areas
- .github/workflows/backend-tests.yml[219-222]
- .npmrc[1-7]

### Suggested change
- Remove the extra/duplicate line and keep just the single intended key.
- (Optional) Drop `cat .npmrc` to reduce log noise, or print only the appended lines.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[JohnMcLear]

Closing — Etherpad has a runtime version check (settings.ts) that refuses to start on Node < 24 with a clear error message. So this probe can't compare flake rate without code changes to bypass the version check, which expands scope considerably. The Node-22-as-comparator hypothesis isn't dead, just not achievable with a workflow-only probe. Worth revisiting as a code change if other probes don't pin down the cause.