Investigate production Next.js/Turbopack client bootstrap errors in Sentry

[spizeck]

Problem

Two unhandled production browser errors appeared in Sentry overnight on the same Sea Saba deployment/release:

08da3607d6825def3e9c11240e0ad9c9050148dc

Both occurred on https://www.seasaba.com/ and both appear inside the Next.js/Turbopack/Sentry client bootstrap path rather than Sea Saba application code.

Event 1

InvariantError: Invariant: Expected document.currentScript to be a <script> element. Received null instead. This is a bug in Next.js.

Characteristics:

• environment: production
• platform: browser/javascript
• mechanism: unhandled promise rejection
• stack dominated by Turbopack runtime chunks
• unsymbolicated
• release: 08da3607...

Event 2

TypeError: WeakMap keys must be objects or non-registered symbols

Characteristics:

• environment: production
• platform: browser/javascript
• mechanism: unhandled promise rejection
• stack passes through Turbopack runtime and Sentry client integration setup
• unsymbolicated
• release: 08da3607...
• Sentry privacy controls appear to be working; no unexpected customer PII observed

Goal

Determine whether these are:

1. a Next.js/Turbopack framework bug,
2. a Sentry + Next.js/Turbopack integration bug,
3. a browser-specific issue,
4. an application-triggered defect,
5. or some combination.

Do not suppress or ignore these events until the cause is understood.

Investigation

Inspect the exact deployed commit/release and current package versions.

At minimum:

• correlate both events to the deployment represented by release 08da3607...
• inspect Next.js, React, Turbopack and @sentry/nextjs versions used by that release
• identify browser/user-agent information retained by Sentry for both events if available
• determine whether both events are Safari/WebKit-specific or cross-browser
• search current upstream Next.js and Sentry issue trackers for the exact error signatures
• inspect whether these errors reproduce against a local/production build
• test repeated page loads/navigation in Chromium and WebKit
• inspect whether Sentry initialization timing contributes to either failure
• inspect whether instrumentation-client.ts, Next.js bootstrapping, or dynamic import/chunk registration is involved
• determine whether the errors predate Sentry integration or began only after Add production-only Sentry error-monitoring baseline (#129) #157
• check whether a currently supported patch/minor update of Next.js or @sentry/nextjs addresses either signature

Use authoritative upstream sources where possible.

Important boundaries

• Do not add a Sentry ignore filter unless the error is proven harmless and unavoidable.
• Do not disable Sentry to make the events disappear.
• Do not make speculative production code changes.
• Do not fold Issue Configure Sentry releases and production source maps #130 source-map/release work into this issue.
• Do not change Dutch localization work.
• Do not upgrade major versions casually.

If a dependency update is recommended, explain exactly which upstream issue/changelog supports it and why.

Source-map context

Issue #130 remains separate and will improve future symbolication.

Current events are unsymbolicated and show js_no_source / bundled _next/static chunks. This investigation should work with the evidence currently available, while recording anything #130 should help clarify later.

Acceptance criteria

• Exact deployment/commit correlated.
• Browser scope identified as far as available evidence allows.
• Upstream Next.js/Sentry issues checked for both exact signatures.
• Reproduction attempted in both Chromium and WebKit.
• Determination made whether Sea Saba code is implicated.
• Determination made whether Sentry initialization is implicated.
• Recommended remediation is evidence-based.
• No blanket suppression.
• If no safe fix is available, document monitoring criteria and when to escalate.

Final report

Report:

1. base/head/branch/PR if code changes are needed
2. exact package versions
3. deployment/release correlation
4. browser/user-agent findings
5. upstream issues found, with links
6. reproduction results
7. root-cause assessment
8. whether the issue appears customer-visible
9. whether Sentry itself contributes
10. whether a dependency update is warranted
11. exact remediation performed or recommended
12. validation results
13. whether any Sentry ignore rule was added (expected: no, unless strongly justified)
14. what Configure Sentry releases and production source maps #130 should carry forward

If investigation finds no code change is justified, do not create a PR solely to create activity. Document the findings on the issue instead.

[spizeck]

Investigation report — Issue #161

Release → commit → deployment correlation

Sentry release 08da3607d6825def3e9c11240e0ad9c9050148dc is exactly:

• Git: master merge commit of Stabilize flaky resize-scroll and footer-widgets Playwright coverage (#159) #160 (Stabilize flaky resize-scroll and footer-widgets Playwright coverage (#159) (#160))
• Vercel: dpl_A8Do677v5QYTRcuMW8H55uE3mMoB, production, READY, aliased to www.seasaba.com, region iad1, built ~2026-09-24T01:42Z
• The release SHA is populated automatically by @sentry/nextjs's Git integration — no explicit release config exists. Preserve this for Configure Sentry releases and production source maps #130.

Exact versions at the affected deployment

Component	Version
Next.js	16.3.5 (Turbopack production build)
React / React DOM	19.3.0
@sentry/nextjs (browser/core/react)	10.74.0
Node	24.x (Vercel); v24.21.0 local
Turbopack runtime	emitted static/chunks/turbopack-<hash>.js registerChunk

Error 1 — Expected document.currentScript to be a <script> element. Received null

Root cause: confirmed upstream Next.js/Turbopack bug — vercel/next.js#91448.

Mechanism (verified in installed + emitted code):

1. Every /_next/static/chunks/*.js entry registers via TURBOPACK.push(...), eagerly capturing document.currentScript during script evaluation.
2. The runtime's registerChunk is async and await Promise.all(otherChunks) runs before it instantiates runtime module IDs.
3. The entry module calls appBootstrap() → getAssetPrefix() (next/dist/client/asset-prefix.js), which reads document.currentScript again, at bootstrap time and throws E783 if it isn't a <script>.
4. When the awaited sibling registration resolves outside script evaluation, document.currentScript is null → invariant throws before hydrate().

Upstream reports the native trigger on Pale Moon plus comments reporting the same signature on desktop Safari, Chrome, Edge, Firefox, Android WebView/Chrome Mobile — it is not WebKit-exclusive.

Customer impact — proven, not theoretical. In the controlled reproduction the page paints SSR HTML but React never attaches (deadHydration on every signature-hit load): all links/forms/carousels are dead until reload. Not harmless noise.

Error 2 — WeakMap keys must be objects or non-registered symbols

• The phrasing is JavaScriptCore's → Safari-family (Chromium would say Invalid value used as weak map key).
• The known Sentry web-vitals WeakMap bug (getsentry/sentry-javascript#18809, iOS Safari 18.6.2, same wording) is already fixed in our @sentry/*@10.74.0 — initUnique is guarded. Error 2 is a different WeakMap path.
• Candidates in the bootstrap bundle include Sentry's browserTracingIntegration (registered by default even with tracesSampleRate: 0) and a React Flight knownServerReferences WeakMap — but the unsymbolicated stack doesn't identify which, and I could not retrieve per-event browser metadata (no Sentry API token available locally; production DSN/env live only in Vercel). Attribution needs Configure Sentry releases and production source maps #130's source maps.

Browser evidence caveat

Sentry did not retain (or I could not access) per-event user-agent/browser fields. Error 2 → Safari-family is a wording-based inference, not verified event metadata. Error 1 is confirmed cross-browser upstream.

Reproduction (local next start, Sentry-active production build)

~106 loads per configuration × 4 configs: cold loads (fresh context), reloads, back/forward nav, hard refreshes, one delayed-sibling-chunk series, plus a CPU-throttled variant — plus a controlled mechanism run that defers one runtime-awaited chunk's TURBOPACK.push behind setTimeout (mirroring what the affected engines do natively).

Config	Loads	Signature hits	Dead hydration
chromium	106	1 (controlled)	1
webkit	106	1 (controlled)	1
chromium + CPU 6×	106	0	0
webkit + throttle	106	1 (controlled)	1

Natural battery: zero hits — consistent with a rare timing/engine edge. Controlled runs reproduced the exact production invariant and dead hydration in both engines.

Is Sentry implicated?

Not causal for Error 1. instrumentation-client.ts is required in the entry module one line above appBootstrap() — Sentry initializes first, which is why it captures the throw; it cannot cause or prevent it. The repo has shipped Next 16.x/Turbopack since before Sentry #129 — the bug almost certainly predates observability; Sentry exposed it. A timing contribution by Sentry init can't be fully excluded but nothing supports it. For Error 2, Sentry is a candidate source (init-time WeakMap paths) but unproven pending symbolication.

Dependency assessment

• Next 16.3.6 (latest stable) and the latest canary still throw E783 — PR #91452 is unmerged. No released upgrade fixes this; do not upgrade casually.
• @sentry/nextjs 10.75.x contains nothing relevant; the 18809 fix is already ours.

Remediation — PR #162

The only fix is the upstream one. #162 vendors PR #91452 via patch-package (postinstall): when document.currentScript isn't a script element, fall back to the last script[src*="/_next/"]; E783 still throws if none exists. Covers dist/client + dist/esm, version-pinned, fails loudly on drift — remove it once a released Next.js ships the fix.

New spec tests/e2e/bootstrap-chunk-registration.spec.ts reproduces the condition deterministically (defers a runtime-awaited chunk across a task boundary) and asserts hydration completes. Verified: fails with the exact production invariant when unpatched; passes patched on Chromium + WebKit. Full validation: check/lint/typecheck clean, 305 unit/integration tests, build:test, 274 e2e pass / 0 fail.

#130 carry-forward

• Release SHA auto-population works — keep it; add explicit release management around it, not instead of it.
• Both events are unsymbolicated stacks into _next/static Turbopack chunks — source maps are what will attribute Error 2's WeakMap and confirm Error 1's frames.

Monitoring / escalation

• Zero new document.currentScript / E783 events expected on the release containing Carry upstream getAssetPrefix fallback for Turbopack bootstrap race (#161) #162 — any occurrence means the fallback itself failed; escalate immediately.
• Error 2: watch event volume after Carry upstream getAssetPrefix fallback for Turbopack bootstrap race (#161) #162 deploys. If it persists/recurs on Safari, prioritize Configure Sentry releases and production source maps #130 symbolication to attribute it before any targeted fix.
• No ignoreErrors, no string suppression, GlobalHandlers untouched.

Keeping this open until #162 merges and post-deploy Sentry confirms E783 is gone.

[spizeck]

New production Sentry evidence: Clarity / ICU error

A new unhandled production browser error appeared after the initial Turbopack investigation:

RangeError: Internal error. Icu error.

Event characteristics:

• release: cc030ca72d67bb5364a0d9e03a6dce4b4546d34d
• route/transaction: /book
• mechanism: auto.browser.browserapierrors.setTimeout
• stack contains multiple frames in 0.8.72-beta/clarity.js
• bottom of stack reaches Intl.DateTimeFormat
• two earlier breadcrumbs in the same session recorded the same RangeError: Internal error. Icu error. before the final unhandled event
• session history shows Cookiebot interaction shortly before the first ICU error
• stack is currently unsymbolicated for app code
• no unexpected customer PII was visible in the event

This looks materially different from the Turbopack document.currentScript bug fixed in PR #162. Current working hypothesis is third-party/browser-runtime behavior involving Microsoft Clarity + Intl.DateTimeFormat / ICU, potentially browser-specific.

Please keep this under #161 alongside the unresolved WeakMap error until attribution is stronger.

Additional investigation needed

• identify browser/user-agent for this event if Sentry retained it
• determine whether it is Safari/WebKit-specific
• investigate current Microsoft Clarity issues/changelog for ICU, Intl.DateTimeFormat, and this exact RangeError wording
• reproduce with Clarity enabled vs disabled under the same browser/session conditions
• check whether Cookiebot consent transitions influence Clarity startup/timing
• determine whether the failure is customer-visible or self-recovers
• do not add an ignore rule unless third-party causality and harmlessness are demonstrated
• do not remove Clarity without evidence
• keep Configure Sentry releases and production source maps #130 separate, but use future symbolication if this recurs

[spizeck]

Investigation report — RangeError: Internal error. Icu error. (Clarity / ICU)

Verdict: conclusively a Microsoft Clarity defect triggered by a browser with a broken/partial ICU implementation. Sea Saba application code is not implicated, and the error is not customer-visible. No code change or PR is justified in this repo. Details and evidence below.

Release / deployment correlation

• Sentry release cc030ca72d67bb5364a0d9e03a6dce4b4546d34d = Vercel production deployment dpl_7MxVFpCaQuUxyC9NY8U9KcvFUbRp (master, READY).
• That build already contains the Carry upstream getAssetPrefix fallback for Turbopack bootstrap race (#161) #162 E783 patch — this error post-dates the Turbopack fix and is confirmed unrelated.

Browser identification — Chromium-family (confirmed by runtime fingerprint, not UA)

• Internal error. Icu error. is V8's MessageTemplate::kIcuError wording — V8/Chromium-family only. Verified in Node (V8): new Intl.DateTimeFormat('de-u-22300-true-x-true') throws exactly RangeError: Internal error. Icu error.
• SpiderMonkey reports JSMSG_INTERNAL_INTL_ERROR ("internal error while computing Intl data") and JavaScriptCore uses different wording entirely — Safari/WebKit and Firefox are ruled out by the message itself. This is the opposite engine family from the unresolved WeakMap error (TypeError: WeakMap keys must be objects… = JSC/Safari wording) → the two errors in this issue are almost certainly different browsers and different causes.
• What I could NOT do: read the event's user-agent/contexts.browser/contexts.os — no Sentry API token is available locally and Vercel env values are encrypted. If someone with Sentry access can check the event's browser/OS context, that would pin the specific client. Candidates for a Chromium-family runtime whose Intl.DateTimeFormat() throws on the default locale: embedded/in-app Chromium (Qt WebEngine, CEF, Android WebView) missing icudtl.dat, niche Chromium forks shipping stripped ICU, or an OS locale Chromium can't canonicalize (documented precedent: WebKit bugzilla 276098 shows a Chromium build throwing exactly this error when linked against improperly-installed ICU).
• Note: our own dataCollection.httpHeaders.request:false privacy config may be why per-event browser metadata is thin — Sentry derives browser context from the ingest request's User-Agent, which we decline to store.

Root cause — exact code path (verified in shipped bundle AND upstream source)

The only Intl call in clarity.js is in metadata.start() (packages/clarity-js/src/data/metadata.ts, unchanged on main):

const timezone = (typeof Intl !== 'undefined' && Intl?.DateTimeFormat()?.resolvedOptions()?.timeZone) ?? '';

Optional chaining guards undefined — it does not catch a throw. In a browser where Intl.DateTimeFormat() (zero-arg, default locale) throws, this propagates:

metadata.start() → measure() catches → report(ex) (Clarity internal diag) → rethrows → aborts data.start() mid-forEach → propagates out of clarity.start().

Two setTimeout-based paths invoke clarity.start, both matching the Sentry mechanism auto.browser.browserapierrors.setTimeout:

1. Consent-denied restart — consentv2(): when analytics_Storage resolves denied while config.track is true → clarity.stop() + window.setTimeout(clarity.start, 250) (Setting.RestartDelay = 250).
2. SPA navigation restart — Clarity hooks history.pushState/replaceState/popstate; on URL change → stop() + window.setTimeout(start, 250).

Because clarity.start() sets active=true and installs the history hooks before running module starts, a failed start leaves the hooks live — so every subsequent client-side navigation re-triggers the throw. That matches the production session: errors after the Cookiebot decline (consent restart) and again at /book (navigation restart). The unsymbolicated _next frame is most plausibly Sentry's own setTimeout instrumentation wrapper (bundled into our chunks) — #130 symbolication can confirm; it's incidental, not causal.

Controlled reproduction (against production www.seasaba.com; Sentry ingest + clarity.ms/collect route-aborted — no test data reached either service)

Method: addInitScript patches Intl.DateTimeFormat to throw RangeError("Internal error. Icu error.") — simulating a broken-ICU V8 runtime. Modes: zero-arg-only (exactly Clarity's call shape) and all-calls (fully broken ICU).

Scenario	Engine	Errors	Site functional
control (healthy ICU), decline + nav /→/plan-your-trip→/visiting-yachts→/book	Chromium	0	yes
zero-arg patch	Chromium	5 — load, decline, each of 3 navs	yes — all navs succeeded, hydration OK, Checkfront embed present on /book
all-calls patch	Chromium	5+, same shape	yes
zero-arg patch + all clarity.ms blocked	Chromium	0	yes
zero-arg patch	WebKit	5 (+1 unrelated Checkfront fullscreen permission-policy noise)	yes

Reproduced stack matches production signature: Intl.DateTimeFormat → start → anonymous clarity.js frames, via browserapierrors.setTimeout. Script: tmp/clarity-icu-repro.mjs (gitignored).

Customer impact — none to the site; Clarity telemetry dies

• The throw lives entirely inside Clarity's own timer callback; it never propagates into React/Next code. Navigation, hydration, and the Checkfront booking embed all kept working in every patched run — consistent with the production session continuing to browse after the errors.
• However, the abort leaves Clarity half-initialized: envelope/upload/ping/upgrade/extract modules (all after metadata in the start order) never run → zero Clarity telemetry is sent for affected sessions (confirmed: no o.clarity.ms/collect requests in patched runs vs. several in control). So this is self-reporting noise in Sentry for sessions that are invisible to Clarity anyway.

Cookiebot relationship — causal as trigger, not as cause

• Decline is one of two restart triggers (consent-denied → 250ms restart → throw). The other is any SPA navigation. Root cause is the browser's ICU + Clarity's unguarded call; Cookiebot merely supplied a state transition.

Privacy/consent observations (separate defect — flagging per instructions)

Observed in the control run (no patch), pre-consent with the banner still unanswered:

• _clck (Clarity) and _uetsid/_uetvid (Microsoft UET — served through www.clarity.ms/tag/uet/…) cookies were already written before any consent decision, and c.clarity.ms/c.gif fired pre-consent. All were cleared after decline (post-decline cookies = only CookieConsent), and Clarity's restart correctly stopped tracking — the decline path itself works.
• This deviates from the documented expectation in docs/COOKIEBOT_CONSENT_SETUP.md §6 case A ("no persistent Clarity cookies" without interaction). Likely causes: the GTM Clarity tag has no analytics_storage additional consent check (it loads unconditionally and relies on Clarity's native google_tag_data.ics GCM listener), and/or the Clarity project's consent/cookieless mode isn't configured to suppress the cookie write before the denied default is processed. This is a GTM/Clarity dashboard configuration question, not a repo code change — recommend reviewing the tag's consent settings and the project's consent mode in the Clarity dashboard.

Upstream status

• Unguarded call present in 0.8.70, 0.8.71, 0.8.72-beta (all three fetched and checked) and in main source — no upstream fix exists. No open issue in microsoft/clarity for this (gh search returned nothing). The fix upstream is a one-line try/catch around the Intl.DateTimeFormat() call — I can file an issue there if you want.
• Clarity version is server-controlled by scripts.clarity.ms; our project's tag currently resolves to 0.8.70 (the event used 0.8.72-beta — staged rollout).

Remediation options (evidence-ranked)

1. File upstream issue at microsoft/clarity (metadata.start should try/catch the timezone read). Real fix; auto-deploys when they ship.
2. GTM consent check — add analytics_storage additional consent check to the Clarity tag: eliminates the error for declined-consent sessions (and fixes the pre-consent cookie issue), but does NOT prevent it for users who accept analytics consent (navigation restarts still throw). Partial mitigation.
3. Narrow Sentry filter — both preconditions are now met (conclusively third-party; provably cannot affect app function). If you want it, the correct implementation is a beforeSend drop keyed on stack frames (all frames on *.clarity.ms), NOT ignoreErrors on the message — the same Internal error. Icu error. message could legitimately fire from our own toLocaleDateString calls (lib/dive-log-export.ts, lib/firestore/dive-log.ts) in a genuinely broken-ICU browser, and we'd want to keep that visibility. Per protocol, reported first — not implemented.
4. Nothing app-side — no code change is justified; do not patch Intl or gate hydration on third-party health.

Relation to the WeakMap error

No shared cause indicated: this event is V8/Chromium; the WeakMap wording is JavaScriptCore/Safari. Different engine families, different stacks, different mechanisms. The WeakMap error remains unresolved and still needs #130 symbolication.

Confirmations

• No ignoreErrors, no fingerprinting hacks, no GlobalHandlers exclusions added — nothing suppressed.
• Configure Sentry releases and production source maps #130 carry-forward: the lone _next frame is likely Sentry's timer instrumentation; source maps would confirm. Also consider whether dataCollection.httpHeaders.request:false should be relaxed for the User-Agent header specifically if browser attribution is wanted for future events.
• Keeping Investigate production Next.js/Turbopack client bootstrap errors in Sentry #161 open for the WeakMap error; this ICU error is understood end-to-end and needs no further action unless we want the Sentry-noise filter or the upstream issue filed.