Skip to content

frontend: isolate page init steps so one failure doesn't abort the rest#3534

Open
reakaleek wants to merge 2 commits into
mainfrom
placid-beat
Open

frontend: isolate page init steps so one failure doesn't abort the rest#3534
reakaleek wants to merge 2 commits into
mainfrom
placid-beat

Conversation

@reakaleek

Copy link
Copy Markdown
Member

Why

The init chain in main.ts runs a sequence of functions on every htmx:load event with no error isolation. A single thrown exception propagates out of the event listener and silently skips every subsequent init call — meaning a bug in initTocNav would also break copy buttons, tabs, math rendering, and everything else on the page.

What

Adds a runInitSteps helper that iterates a named list of init functions and wraps each call in a try/catch. Failures are logged to console.error (always visible in DevTools) and to the existing logError from telemetry/logging.ts (structured, sent to the backend when telemetry is enabled). Both DOMContentLoaded and htmx:load blocks are converted to use it.

The ?edit query-param inline block is extracted into applyEditParam so it fits the same guarded list.

How

Step names are passed as explicit strings rather than derived from fn.name so they survive Parcel minification and remain stable in production error logs.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jun 18, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

Warning

Review limit reached

@reakaleek, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 44 minutes and 34 seconds. Learn how PR review limits work.

Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file).

⌛ How to resolve this issue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits.

🚦 How do rate limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: 19487e7a-6133-40bc-87cc-1a0498468c4b

📥 Commits

Reviewing files that changed from the base of the PR and between 1b8ab89 and d6b6f9d.

📒 Files selected for processing (1)
  • src/Elastic.Documentation.Site/Assets/main.ts
📝 Walkthrough

Walkthrough

main.ts adds a logError import and two new helpers: runInitSteps, which iterates an array of initialization functions and wraps each in a try/catch that calls both console.error and logError on failure, and applyEditParam, which reads the edit URL query parameter and removes the hidden class from .edit-this-page when the parameter is present. The DOMContentLoaded handler is updated to invoke initMath and initMermaid through runInitSteps, and the htmx:load handler is consolidated into a single runInitSteps call that includes applyEditParam alongside the existing page initializers.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title directly and concisely describes the main change: refactoring init steps to prevent one failure from aborting the rest, which matches the core objective.
Description check ✅ Passed The description is well-detailed and directly related to the changeset, explaining the problem, solution, and implementation approach for error isolation in page initialization.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
✨ Simplify code
  • Create PR with simplified code
  • Commit simplified code in branch placid-beat

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/Elastic.Documentation.Site/Assets/main.ts`:
- Around line 58-72: The runInitSteps function accepts init functions but does
not await them, causing async function errors to escape the try/catch block as
unhandled promise rejections. Make the runInitSteps function itself async, await
the init() call inside the try block, and update the function signature to
accept functions that return either void or Promise<void>. Additionally, update
all event handlers and callers that invoke runInitSteps to await the returned
promise so that error handling works correctly for both synchronous and
asynchronous initialization steps.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: fca9bbd5-05b8-42e4-891a-7ec41a9b8553

📥 Commits

Reviewing files that changed from the base of the PR and between 90614f2 and 1b8ab89.

📒 Files selected for processing (1)
  • src/Elastic.Documentation.Site/Assets/main.ts

Comment thread src/Elastic.Documentation.Site/Assets/main.ts
…ections

initMermaid is async; without await the try/catch silently misses its
rejected promise. Event handlers are left synchronous — the browser
ignores listener return values and runInitSteps never rejects externally.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant