Preliminary Checks
Summary
Same exact error string and stack frame as #3996 is firing in production on @clerk/clerk-js@5.125.10 (CDN-served bundle), but on a different stack (TanStack Start instead of Next.js). This confirms the bug is internal to the field-controller code path and framework-agnostic. I'm filing a fresh report because #3996 was auto-closed for lack of repro and is now locked.
Error
TypeError: e.clearFeedback is not a function.
(In 'e.clearFeedback()', 'e.clearFeedback' is undefined)
Stack frame
/npm/@clerk/clerk-js@5.125.10/dist/ui-common_clerk.browser_75d171_5.125.10.js:118
// minified excerpt:
e)===e.id),n=t(r); r.length && n ? e.setError(n) : e.clearFeedback()
The field controller object `e` has `setError` defined but not `clearFeedback`. Originating PRs that introduced this code path: #2399, #2409, #2413 (Dec 2023).
Reproduction
I don't have a reliable minimal repro — like the original reporter, this is caught in production via Sentry's `onunhandledrejection` global handler. The form continues to function for the user; the throw is caught and logged but doesn't surface user-visible breakage.
What I can confirm:
- Browser: Safari 18.6 / macOS 10.15.7+
- React: 19.2.2
- Stack: TanStack Start 1.131.2 + `@clerk/tanstack-react-start@0.25.3` + `@clerk/clerk-react@5.58.1`
- Mount: `<SignUp routing="hash" afterSignUpUrl="/onboarding" unsafeMetadata={...} />`
- Mechanism: `auto.browser.global_handlers.onunhandledrejection`
I have a Sentry session replay available on request — happy to share via DM if a maintainer wants to see the user's interaction sequence (the previous report's Sentry link was inaccessible due to org login; a replay export would solve that).
Why this is worth re-opening
- The `setError(n) : clearFeedback()` ternary assumes `clearFeedback` is always defined when `setError` is. There's a missing guard.
- 18 months between the original report (Aug 2024) and this re-occurrence (May 2026) suggests the code path is rare-but-real. Either:
(a) some field-controller variant skips the `clearFeedback` binding,
(b) Safari-specific timing exposes a window where the controller object is partially initialized, or
(c) browser extension interference replaces the controller object.
Suggested fix (drive-by)
Defensive null-check at the call site would be ~2 lines and eliminate the class entirely:
```js
e.setError(n) : e.clearFeedback?.()
```
This won't fix the root cause (whatever creates a controller without `clearFeedback`), but it would convert this from an unhandled rejection into silent best-effort behavior, which matches the existing intent.
Preliminary Checks
Summary
Same exact error string and stack frame as #3996 is firing in production on
@clerk/clerk-js@5.125.10(CDN-served bundle), but on a different stack (TanStack Start instead of Next.js). This confirms the bug is internal to the field-controller code path and framework-agnostic. I'm filing a fresh report because #3996 was auto-closed for lack of repro and is now locked.Error
Stack frame
/npm/@clerk/clerk-js@5.125.10/dist/ui-common_clerk.browser_75d171_5.125.10.js:118The field controller object `e` has `setError` defined but not `clearFeedback`. Originating PRs that introduced this code path: #2399, #2409, #2413 (Dec 2023).
Reproduction
I don't have a reliable minimal repro — like the original reporter, this is caught in production via Sentry's `onunhandledrejection` global handler. The form continues to function for the user; the throw is caught and logged but doesn't surface user-visible breakage.
What I can confirm:
I have a Sentry session replay available on request — happy to share via DM if a maintainer wants to see the user's interaction sequence (the previous report's Sentry link was inaccessible due to org login; a replay export would solve that).
Why this is worth re-opening
(a) some field-controller variant skips the `clearFeedback` binding,
(b) Safari-specific timing exposes a window where the controller object is partially initialized, or
(c) browser extension interference replaces the controller object.
Suggested fix (drive-by)
Defensive null-check at the call site would be ~2 lines and eliminate the class entirely:
```js
e.setError(n) : e.clearFeedback?.()
```
This won't fix the root cause (whatever creates a controller without `clearFeedback`), but it would convert this from an unhandled rejection into silent best-effort behavior, which matches the existing intent.