fix(ci): remove NODE_OPTIONS causing OOM in Algolia workflow

[sergical]

DESCRIBE YOUR PR

The Algolia user docs build has been increasingly flaky since late March and is now failing ~100% of the time. All failures show the same pattern: exit code 143 (SIGTERM) with "runner received shutdown signal" after ~56 minutes — the runner is being OOM-killed.

Root cause

The NODE_OPTIONS: '--max-old-space-size=6144' setting (added in #17283 on April 9 as an attempted fix) tells Node it can allocate up to 6 GB heap on a 7 GB runner, leaving only ~1 GB for the OS/kernel — triggering the OOM killer.

Evidence

The lint-404s workflow does the same pnpm build → next build on the same ubuntu-latest runner without NODE_OPTIONS and has a 0% failure rate. The algolia workflow — identical build but with NODE_OPTIONS=6144 — has been failing consistently.

Before April 9 (no NODE_OPTIONS, no .next/cache), the workflow was already flaky at ~30-40%. The April 9 fix added both cache (which helps) and NODE_OPTIONS (which hurts), netting a worse outcome. This PR keeps the cache but removes NODE_OPTIONS.

Timeline

• Late March: Failures start appearing (~5-30% rate), no NODE_OPTIONS, no build cache
• April 9 (fix(ci): resolve OOM in Algolia index workflow #17283): Added NODE_OPTIONS=6144 + .next/cache — failure rate increased to ~50-65%
• Late April–now: User docs build has not succeeded once since April 28

What this PR does

• Removes NODE_OPTIONS: '--max-old-space-size=6144' (the main culprit)
• Removes unnecessary generate-og-images from the user docs build step

What this does NOT do

• We cannot 100% verify locally because we can't replicate the 7 GB memory constraint of the GitHub Actions runner. The strongest evidence is the lint-404s comparison (same build, same runner, no NODE_OPTIONS, 0% failure rate).

IS YOUR CHANGE URGENT?

Help us prioritize incoming PRs by letting us know when the change needs to go live.

• Urgent deadline (GA date, etc.):
• Other deadline: Algolia search index for user docs hasn't been updated since April 28
• None: Not urgent, can wait up to 1 week+

SLA

• Teamwork makes the dream work, so please add a reviewer to your PRs.
• Please give the docs team up to 1 week to review your PR unless you've added an urgent due date to it.
  Thanks in advance for your help!

PRE-MERGE CHECKLIST

Make sure you've checked the following before merging your changes:

• Checked Vercel preview for correctness, including links
• PR was reviewed and approved by any necessary SMEs (subject matter experts)
• PR was reviewed and approved by a member of the Sentry docs team

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
develop-docs	Ready	Preview, Comment	May 11, 2026 5:59pm
sentry-docs	Ready	Preview, Comment	May 11, 2026 5:59pm

[sentry]

Bug: The shared concurrency key can cause a new push to cancel an in-progress documentation update, leading to a stale search index for the cancelled job.
_{Severity: MEDIUM}

Suggested Fix

Modify the concurrency group key to be unique for each documentation type. For example, incorporate the output of the path filter step into the key, such as ${{ github.workflow }}-${{ github.ref }}-${{ steps.filter.outputs.user_docs }}-${{ steps.filter.outputs.dev_docs }}, to prevent unrelated updates from cancelling each other.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: .github/workflows/algolia-index.yml#L14-L17

Potential issue: The GitHub Actions workflow uses a `concurrency` group key that is
identical for all pushes to the `master` branch. Due to `cancel-in-progress: true`, a
new push can cancel an in-progress workflow run. The workflow has separate conditional
steps for updating user and developer documentation based on file paths. If a push
updating user docs cancels a run that was updating developer docs, the new run will not
re-trigger the developer docs update. This is because the path filter only evaluates
files in the new push, causing the developer documentation search index to become
silently stale. The long build times for each documentation set make this race condition
likely.

_{Did we get this right? 👍 / 👎 to inform future reviews.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f365b48. Configure here.}

[cursor]

NODE_OPTIONS removed instead of bumped to 12 GB

High Severity

The NODE_OPTIONS: '--max-old-space-size=6144' env var was removed entirely instead of being bumped to 12 GB (--max-old-space-size=12288) as the PR description states. Without this setting, Node.js defaults to a ~2–4 GB heap limit — significantly less than the previous 6 GB. Since the build was already OOM-killing at 6 GB, removing the heap override will make the OOM problem worse, not better. The runner also remains ubuntu-latest rather than ubuntu-latest-4core as described.

 

^{Reviewed by Cursor Bugbot for commit f365b48. Configure here.}

[sfanahata]

@sergical I know you said this is one that we need to push to see, so looks fine except for the cursor bot comment that looks like it might be an issue. Mind checking that before merging?

[sergical]

@sfanahata yeah i rmeoved it instead of bumping because lint-404 workflow isn't failing the next build step with any configuration so i just want to validate that the default config actually solves the problem vs bumping the config