chore: re-enable open-next build check

[dario-piotrowicz]

Description

The open-next playwright build check is currently not functional and the open-next build is also not working, my PR is addressing these issues by:

• updating the github workflow to downgrade the Next.js version being used
  (necessary workaround since chore: downgrade Next.js to 15.3.2 to support the open-next adapter #8019 didn't land)
  (note: even if not on the same Next.js version I think it's still important to keep the CI check functioning so that we make sure that the open-next compatibility doesn't unknowingly break for some unrelated reasons)
• bumping the @flarelabs-net/wrangler-build-time-fs-assets-polyfilling
  (this is needed because since feat: pills on footer and clean up code #7999 the site uses glob from node:fs/promises) which wasn't polyfilled by the package

Validation

I run the workflow on my for of the repository and it seems to be working as expected: https://github.com/dario-piotrowicz/nodejs.org/actions/runs/16576981245/job/46884037779

Related Issues

Important

The workflow has been manually disable on GitHub

Can it be re-enabled?
Could I know what the cause for disabling it was?
I assume it was due to its flakiness but haven't had anyone directly confirming that
If it was flakiness I am definitely happy to look into addressing that next, although on my fork I cannot seem
to be able to repro the flakiness right now:

(could it just have gone away by itself? 😕)

Check List

• I have read the Contributing Guidelines and made commit messages that follow the guideline.
• I have run pnpm format to ensure the code follows the style guide.
• I have run pnpm test to check if all tests are passing.
• I have run pnpm build to check if the website builds without errors.
• I've covered new added functionality with unit tests if necessary.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated (UTC)
nodejs-org	✅ Ready (Inspect)	Visit Preview	Jul 30, 2025 2:24pm

[Copilot]

Pull Request Overview

This PR re-enables the currently disabled open-next build check by addressing compatibility issues between the current Next.js version and open-next. The changes ensure the CI workflow continues to function properly for open-next compatibility testing.

• Downgrades Next.js to version 15.3.2 as a temporary workaround for open-next compatibility issues
• Updates the @flarelabs-net/wrangler-build-time-fs-assets-polyfilling package to support new glob usage from node:fs/promises

Reviewed Changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
.github/workflows/playwright-cloudflare-open-next.yml	Adds a step to downgrade Next.js to 15.3.2 for open-next compatibility
apps/site/package.json	Bumps the wrangler build-time fs assets polyfilling package to version 0.0.1

Files not reviewed (1)

• pnpm-lock.yaml: Language not supported

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 73.02%. Comparing base (ef5dc84) to head (08df8f7).
⚠️ Report is 1 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #8039      +/-   ##
==========================================
+ Coverage   72.96%   73.02%   +0.06%     
==========================================
  Files          95       95              
  Lines        8324     8324              
  Branches      215      214       -1     
==========================================
+ Hits         6074     6079       +5     
+ Misses       2249     2244       -5     
  Partials        1        1              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[avivkeller]

Could I know what the cause for disabling it was?
I assume it was due to its flakiness but haven't had anyone directly confirming that

Yes. The workflow had a almost 20% flake rate, so it was disabled.

[dario-piotrowicz]

Could I know what the cause for disabling it was?
I assume it was due to its flakiness but haven't had anyone directly confirming that

Yes. The workflow had a almost 20% flake rate, so it was disabled.

Ok, thanks for confirming that

As I said I'd be very happy to look into fixing that next if we could re-enable the workflow 🙏
(although as I mentioned I could not repro it on my fork... hopefully the flakiness is either gone or it will be reproducible 😅)

[avivkeller]

I'm okay re-enabling it in a "probationary"-like status, i.e. if the flakes continue, it should be disabled again, wdyt?

[dario-piotrowicz]

I'm okay re-enabling it in a "probationary"-like status, i.e. if the flakes continue, it should be disabled again, wdyt?

Of course, as I mentioned a few days ago before the workflow got disabled, I already intended to address the flakiness as I agree that it is not acceptable (and I didn't know it was as high as 20% 😓)

---

On my fork it really is not flaking at all (there is an unrelated small playwright flake which doesn't seem too worrying right now), not sure if that's a good or bad sign 😕

[ovflowd]

OOC, is this PR aiming to fix the flakiness or just re-enable the checks?

[ovflowd]

SGTM

[dario-piotrowicz]

OOC, is this PR aiming to fix the flakiness or just re-enable the checks?

re-enable the check, I also wanted to fix the flakiness here but I can't reproduce it on my fork... so I am actually not sure if the flakiness is still there (hopefully it is not 😅 🤞 )

Assuming that the flakiness is still there (cause realistically I don't fully expect it to have gone away just like that by itself 😅) I will look into address it right away!

[github-actions]

Lighthouse Results

URL	Performance	Accessibility	Best Practices	SEO	Report
/en	🟢 96	🟢 100	🟢 100	🟢 100	🔗
/en/about	🟢 100	🟢 97	🟢 100	🟠 88	🔗
/en/about/previous-releases	🟢 97	🟢 93	🟢 100	🟠 89	🔗
/en/download	🟢 96	🟢 100	🟢 100	🟢 100	🔗
/en/blog	🟢 100	🟢 100	🟢 96	🟢 100	🔗

[avivkeller]

I've done some digging, and:

There was a bug where, if the GitHub API errored out, it would cause an object to be returned instead of an array, leading to .map not being defined.

The bug was fixed in 439f978.

Soooo the OpenNext generator was never flaky, it just came across a bug.