[$250] [Sentry: APP-CN8] Web Cannot call a class as a function on /search

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-CN8

Impact (snapshot at filing)

• Users (total since first seen): 44
• Events: 148
• Users (last 14d, 9.4.x releases): 18
• First seen: 2026-05-11
• Last seen: ongoing
• Platform: web (Safari)
• App version(s): 9.4.5–9.4.9
• Affected route(s): /search
• Mechanism: auto.browser.global_handlers.onunhandledrejection

Stack trace (top frames, first-party only)

TypeError: Cannot call a class as a function
/search (minified bundle frames)

Suspected cause

A class constructor is invoked without new somewhere in the Search page bundle; needs source-map investigation.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Prior GH issues: none

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067266081449625737
• Upwork Job ID: 2067266081449625737
• Last Price Increase: 2026-06-24

Issue Owner

Current Issue Owner: @WojtekBoman

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022067266081449625737

[godzillaxbox19982014-lgtm]

Proposal

Please re-state the problem that we are trying to solve in this issue.

[$250] [Sentry: APP-CN8] Web Cannot call a class as a function on /search

What is the root cause of that problem?

I traced this to the path that handles APP, CN8, TypeError:

• src/components/Search/FilterComponents/UserSelector.tsx:21 (UserSelector): function UserSelector({value = [], selectionListTextInputStyle, selectionListStyle, autoFocus, ready = true, footer, onChange}: UserSelectorProps) {
• src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx:49 (getFilterSentryLabel): function getFilterSentryLabel(filterKey: SearchAdvancedFiltersKey | SearchFilterKey | ReportFieldKey) {
• src/pages/Search/SearchAdvancedFiltersPage/SearchFiltersTagPage.tsx:21 (SearchFiltersTagPage): function SearchFiltersTagPage() {
• The local evidence matches this recurring failure shape: UI sentinel values are serialized as literal search tokens instead of semantic predicates. Here, src/components/Search/FilterComponents/UserSelector.tsx:21 and src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx:49 do not agree on the same APP, CN8, TypeError value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

The search/filter value ledger needs to stay explicit:

• User action: [$250] [Sentry: APP-CN8] Web Cannot call a class as a function on /search
• UI/form value: the first referenced Search UI path (src/components/Search/FilterComponents/UserSelector.tsx:21) creates the visible filter/chip state.
• Query/navigation value: the adjacent parser or query builder (src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx:49) must serialize the same semantic value, not only the display label.
• Result semantics: the search result selector/API must consume that semantic value consistently.
• Reverse/display path: saved URL/query parsing must reopen the same advanced filter and chip state, so the fix is not one-way only.

What changes do you think we should make in order to solve the problem?

• Update src/components/Search/FilterComponents/UserSelector.tsx:21 to derive APP, CN8, TypeError from the search/saved-view state that owns this flow before the value is consumed.
• Carry the same normalized value through src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx:49; that follows the safer family move to write the value ledger before proposing: user action -> UI/form value -> serialized query/navigation token -> search/API meaning -> stored data shape -> reverse parser/display path, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Search, Filters, Grouping, Autocomplete surface and avoid changing large result lists, saved search URLs.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/Search*.ts for the exact issue flow: [$250] [Sentry: APP-CN8] Web Cannot call a class as a function on /search.
2. Cover the counter-case near src/components/Search/FilterComponents/UserSelector.tsx:21 so valid existing APP, CN8, TypeError behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, CN8, TypeError consistent at the first read/write boundary shown above.

[Abdulloh0109]

Proposal

What is the root cause of that problem?

TypeError: Cannot call a class as a function is the exact string Babel's _classCallCheck helper throws when a transpiled ES class is invoked without working new/instanceof semantics. So the crash itself proves the production web bundle lowers some ES class to ES5 on the /search path — and there's exactly one such class, which we inject ourselves at build time.

The autocomplete parser is post-processed by scripts/parser-workletization.sh after Peggy generates it (wired in package.json). That script does three string edits: prepend 'worklet' + an empty class peg$SyntaxError{}, sed s/function peg$SyntaxError/function temporary/ (which renames the real constructor into dead code), and strip peg$subclass(peg$SyntaxError, Error).

You can see the result in the committed output: autocompleteParser.js:1-3 is the injected empty class, and the original constructor is now an orphan at autocompleteParser.js:20-31 (function temporary, never called). Yet the parser still constructs the symbol on its error branch — peg$buildSimpleError / peg$buildStructuredError both do new peg$SyntaxError(...). Contrast the non-worklet searchParser.js:21-34, which keeps peg$SyntaxError as a plain function + peg$subclass(...) and never crashes.

Why new ... still throws "called without new" comes down to where this runs. The parser is handed to the search input as a 'worklet':

• SearchAutocompleteInput.tsx:189-193 wraps parseForLiveMarkdown in a 'worklet', and line 255 passes it as parser={parser} to the live-markdown TextInput.
• That parser runs on a dedicated LiveMarkdown worklet runtime (react-native-live-markdown), evidenced by scheduleOnLiveMarkdownRuntime. On native that runtime is Hermes, which executes real ES classes, so new peg$SyntaxError() is fine. On web, the worklet runtime re-evaluates the serialized worklet source/closure (the whole 'worklet'-flagged autocompleteParser.js module gets pulled in). The Babel-lowered class peg$SyntaxError is re-created as a fresh function in that realm, so the _classCallCheck(this, peg$SyntaxError) guard's instanceof self-check no longer matches — and it throws even though we wrote new.

Every detail in the Sentry snapshot follows from this:

• Web/Safari only — native runs real classes; only the lowered web bundle carries _classCallCheck.
• Intermittent (44 users) — it only fires when the in-progress query is unparseable, i.e. the parser actually reaches the SyntaxError branch.
• onunhandledrejection — parseForLiveMarkdown has no try/catch (unlike parseForAutocomplete, which swallows the identical throw), so on the async runtime path the error escapes as an unhandled rejection on /search.

The only piece I haven't pinned to a literal line is the re-eval inside the live-markdown/Reanimated web runtime (it's in the minified bundle), but the root — we emit an ES class for a value that's new-ed inside a worklet runtime — is certain, and _classCallCheck is the sole source of this message.

What changes do you think we should make in order to solve the problem?

Fix layer is codegen/build — scripts/parser-workletization.sh — then regenerate.

Stop emitting peg$SyntaxError as an ES class. The script only swapped to a class to drop the worklet-unfriendly Error.call(this) / Object.setPrototypeOf / peg$subclass machinery — but a plain function constructor does that too, and Babel never wraps an ordinary function with _classCallCheck. So instead of injecting class peg$SyntaxError{} and renaming the constructor to a dead temporary, keep peg$SyntaxError as a function and strip only the Error-subclassing lines, assigning message/expected/found/location straight onto this. A plain-function new peg$SyntaxError(...) is safe in both the worklet runtime and the lowered web bundle. Then run npm run generate-autocomplete-parser and commit the regenerated file.

Worth doing alongside as defense-in-depth (not a substitute): wrap parse(input) in parseForLiveMarkdown in a try/catch returning [], mirroring parseForAutocomplete. That stops the unhandled rejection on the current build immediately, but it leaves the broken error object in place, so it shouldn't replace the script fix.

Edge cases touched: only the parser's error branch (malformed/in-progress queries); the happy path never builds a peg$SyntaxError, so successful autocomplete/highlighting is unaffected, and web + native then share the same regenerated function.

What alternative solutions did you explore? (Optional)

• Blame searchParser.js. Rejected: it isn't workletized — it keeps function peg$SyntaxError + peg$subclass(...) (searchParser.js:21-34), so Babel never produces a _classCallCheck class for it, and it doesn't run on the live-markdown runtime. The signature can't come from there.
• An app-level React class component on /search called without new. Rejected: this is an onunhandledrejection correlated with typing into the search field, not a synchronous render throw; a mis-rendered class component would fail in React's render path and wouldn't be input-dependent. The only transpiled class reachable on the live-parse error path is peg$SyntaxError.
• Force the parser files to stay native classes via a Babel/browserslist override. Rejected as the primary fix: it fights the toolchain for every browser target and risks other lowering assumptions; turning the one symbol back into a plain function is local to the script and provably avoids _classCallCheck.

[lorretheboy]

Proposal

What is the root cause of that problem?

autocompleteParser.js is post-processed after Peggy generates it by scripts/parser-workletization.sh, which mangles the peg$SyntaxError definition. The script prepends an empty class stub, renames the real Peggy constructor function peg$SyntaxError to a dead temporary function, and deletes the peg$subclass(peg$SyntaxError, Error) linkage:

App/scripts/parser-workletization.sh

Line 15 in 6513211

if awk 'BEGIN { print "\47worklet\47\n\nclass peg\$SyntaxError{}" } 1' "$filePath" | sed 's/function peg\$SyntaxError/function temporary/g' | sed 's/peg$subclass(peg$SyntaxError, Error);//g' > tmp.txt; then

So the shipped parser starts with an empty ES class instead of an Error subclass:

App/src/libs/SearchParser/autocompleteParser.js

Lines 1 to 3 in 6513211

	'worklet'
	class peg$SyntaxError{}

Compare the correct, untouched searchParser.js, where peg$SyntaxError is a real constructor function wired to Error:

App/src/libs/SearchParser/searchParser.js

Lines 21 to 34 in 6513211

	function peg$SyntaxError(message, expected, found, location) {
	var self = Error.call(this, message);
	// istanbul ignore next Check is a necessary evil to support older environments
	if (Object.setPrototypeOf) {
	Object.setPrototypeOf(self, peg$SyntaxError.prototype);
	}
	self.expected = expected;
	self.found = found;
	self.location = location;
	self.name = "SyntaxError";
	return self;
	}
	peg$subclass(peg$SyntaxError, Error);

Causal chain: when an autocomplete query fails to parse, the parser's error path runs new peg$SyntaxError(...):

App/src/libs/SearchParser/autocompleteParser.js

Lines 752 to 763 in 6513211

	function peg$buildSimpleError(message, location) {
	return new peg$SyntaxError(message, null, null, location);
	}
	function peg$buildStructuredError(expected, found, location) {
	return new peg$SyntaxError(
	peg$SyntaxError.buildMessage(expected, found),
	expected,
	found,
	location
	);
	}

Because that identifier is now an empty class (with the Error plumbing stripped), Babel down-levels it for the older Safari targets in the 9.4.x browserslist into a _classCallCheck-guarded constructor. Instantiating that mangled class in the error path throws TypeError: Cannot call a class as a function, which is uncaught and surfaces as an onunhandledrejection on /search. The parser is invoked on every keystroke in the search bar:

App/src/libs/SearchAutocompleteUtils.ts

Line 18 in 6513211

const parsedAutocomplete = parse(text) as SearchAutocompleteResult;

This only fires when the typed query isn't valid grammar, which is why it's intermittent rather than affecting every Safari user.

What changes do you think we should make in order to solve the problem?

Fix the workletization script so it produces a worklet-safe peg$SyntaxError that is still a usable constructor, instead of an empty class with no Error inheritance.

App/scripts/parser-workletization.sh

Line 15 in 6513211

if awk 'BEGIN { print "\47worklet\47\n\nclass peg\$SyntaxError{}" } 1' "$filePath" | sed 's/function peg\$SyntaxError/function temporary/g' | sed 's/peg$subclass(peg$SyntaxError, Error);//g' > tmp.txt; then

The reason worklets reject the original Peggy code is the Error.call(this, ...) / Object.setPrototypeOf pattern, not the constructor itself. So keep peg$SyntaxError as a plain function the parser can new, and only neutralize the unsupported parts — e.g. keep the renamed body but assign it back (const peg$SyntaxError = temporary;) with the Error.call/setPrototypeOf lines made worklet-safe, rather than replacing the whole thing with class peg$SyntaxError{} and dropping peg$subclass. Then regenerate the parser via generate-autocomplete-parser and verify the regenerated autocompleteParser.js no longer contains an empty class.

What alternative solutions did you explore? (Optional)

Wrap the parse(...) calls in SearchAutocompleteUtils.ts in try/catch so a parser throw degrades gracefully instead of becoming an unhandled rejection. This stops the Sentry crash but is a workaround — the parser's error reporting would still be broken, so it should accompany, not replace, the script fix.

[MelvinBot]

Proposal

What is the root cause of that problem?

The /search route loads src/libs/SearchParser/autocompleteParser.js (imported transitively via SearchQueryUtils and every SearchRouter helper). The top of that generated file is not stock Peggy output — it is rewritten by scripts/parser-workletization.sh, which makes the parser worklet-compatible by:

1. prepending a 'worklet' directive and an empty class peg$SyntaxError{},
2. renaming the real function peg$SyntaxError(...) constructor to a now-dead function temporary(...), and
3. deleting the peg$subclass(peg$SyntaxError, Error); call.

Because the file carries the 'worklet' directive, the web build's react-native-worklets/plugin runs @babel/plugin-transform-classes on that class — which is the only place in the /search bundle that down-levels a class and injects Babel's _classCallCheck helper. _classCallCheck is exactly what throws TypeError: Cannot call a class as a function. The error surfaces under onunhandledrejection because the parser's error path (new peg$SyntaxError(...)) runs when a typed autocomplete query fails to parse.

The sibling parser searchParser.js is not rewritten, keeps the plain function peg$SyntaxError, and does not crash — confirming the workletization rewrite is the differentiator.

Evidence

• The error string originates from node_modules/@babel/runtime/helpers/classCallCheck.js: throw new TypeError("Cannot call a class as a function").
• autocompleteParser.js:1-3 — 'worklet' directive + empty class peg$SyntaxError{}.
• autocompleteParser.js:20-31 — orphaned function temporary(...) (the original constructor body, never called).
• parser-workletization.sh:15 — the exact awk/sed rewrite that produces the empty class.
• The web babel preset includes react-native-worklets/plugin; with @babel/preset-env targeting node 20, classes are otherwise left native, so this plugin is the sole source of an emitted _classCallCheck.

Why Safari-only / confidence: High confidence that the broken workletized class + the worklets class transform is the source of the _classCallCheck error on /search. Medium confidence on the precise reason it manifests only on Safari (likely Safari's stricter handling of the worklets-rewritten/factory-wrapped class binding); a Sentry stack frame showing classCallCheck.js → peg$buildStructuredError/peg$SyntaxError would fully confirm.

What changes do you think we should make in order to solve the problem?

Stop emitting peg$SyntaxError as a class in the workletization script so the worklets Babel plugin never runs the class transform that inserts _classCallCheck. Emit it as a plain function (the same shape Peggy already produces in searchParser.js), which is both worklet-safe and web-safe.

In scripts/parser-workletization.sh, run the sed renames before prepending, and prepend function peg$SyntaxError(){} instead of class peg$SyntaxError{} (ordering matters so the rename doesn't clobber the new stub). Then regenerate autocompleteParser.js via the generate-autocomplete-parser script and commit the regenerated file.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. A test that imports @libs/SearchParser/autocompleteParser and asserts that triggering a parse failure (an unparseable autocomplete query) throws/handles cleanly without a Cannot call a class as a function error.
2. A guard that asserts the generated autocompleteParser.js contains no class declaration (so future regenerations can't reintroduce the workletized class).
3. Re-run the existing tests/unit/Search* suites to confirm valid autocomplete parsing still works.

What alternative solutions did you explore? (Optional)

Restore the full peg$subclass(peg$SyntaxError, Error) constructor — rejected because that's the construct worklets can't support, which is why the script stubbed it in the first place. Keeping a plain empty function preserves the current degraded-error intent while removing the class transform.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-17 16:11:58 UTC.

Proposal

What is the root cause of that problem?

The crash is coming from the Search autocomplete parser worklet, not from the Search chart number formatter.

The deployed 9.4.9 web bundle maps the exact TypeError("Cannot call a class as a function") helper back to src/libs/SearchParser/autocompleteParser.js. In the local source at

App/src/libs/SearchParser/autocompleteParser.js

Lines 1 to 3 in 6ea10e7

	'worklet'
	class peg$SyntaxError{}

, that generated file begins with a workletization shim that inserts class peg$SyntaxError{}. The shim comes from

App/scripts/parser-workletization.sh

Lines 14 to 16 in 6ea10e7

	# shellcheck disable=SC2016
	if awk 'BEGIN { print "\47worklet\47\n\nclass peg\$SyntaxError{}" } 1' "$filePath" | sed 's/function peg\$SyntaxError/function temporary/g' | sed 's/peg$subclass(peg$SyntaxError, Error);//g' > tmp.txt; then
	mv tmp.txt "$filePath"

, which prepends that class and renames Peggy's original function peg$SyntaxError constructor to temporary.

Search uses that parser inside the live markdown input path: SearchAutocompleteInput passes a worklet parser to the input at

App/src/components/Search/SearchAutocompleteInput.tsx

Lines 188 to 193 in 6ea10e7

	const currentUserDisplayName = currentUserPersonalDetails.displayName ?? '';
	const parser = (input: string) => {
	'worklet';
	return parseForLiveMarkdown(input, currentUserDisplayName, substitutionMap, emailListSharedValue, currencySharedValue, categorySharedValue, tagSharedValue, exportedToSharedValue);
	};

, and parseForLiveMarkdown calls the generated autocomplete parser at

App/src/libs/SearchAutocompleteUtils.ts

Lines 263 to 276 in 6ea10e7

	function parseForLiveMarkdown(
	input: string,
	currentUserName: string,
	map: SubstitutionMap,
	userLogins: SharedValue<string[]>,
	currencyList: SharedValue<string[]>,
	categoryList: SharedValue<string[]>,
	tagList: SharedValue<string[]>,
	exportedToList: SharedValue<string[]>,
	): MarkdownRange[] {
	'worklet';
	const parsedAutocomplete = parse(input) as SearchAutocompleteResult;
	const ranges = parsedAutocomplete.ranges;

. When react-native-worklets processes that parser, it turns the inserted peg$SyntaxError class into a worklet class factory and emits the _classCallCheck_autocompleteParserJs5 helper that throws this exact Safari Sentry error. Because parseForLiveMarkdown calls parse(input) without the defensive try/catch used by the non-worklet autocomplete helper at

App/src/libs/SearchAutocompleteUtils.ts

Lines 16 to 22 in 6ea10e7

	function parseForAutocomplete(text: string) {
	try {
	const parsedAutocomplete = parse(text) as SearchAutocompleteResult;
	return parsedAutocomplete;
	} catch (e) {
	console.error(`Error when parsing autocomplete query"`, e);
	}

, that transformed parser error can bubble out of the Search page.

What changes do you think we should make in order to solve the problem?

Update the autocomplete parser workletization path so the generated parser no longer contains a JavaScript class for peg$SyntaxError.

Specifically, change scripts/parser-workletization.sh to keep/insert a plain function-compatible peg$SyntaxError constructor for the workletized parser instead of class peg$SyntaxError{}. The replacement should still populate message, expected, found, location, and name, and it should keep the existing format and buildMessage static/prototype helpers usable. Then regenerate src/libs/SearchParser/autocompleteParser.js via the existing generate-autocomplete-parser script from

App/package.json

Lines 77 to 78 in 6ea10e7

	"generate-search-parser": "peggy --format es -o src/libs/SearchParser/searchParser.js src/libs/SearchParser/searchParser.peggy src/libs/SearchParser/baseRules.peggy",
	"generate-autocomplete-parser": "peggy --format es -o src/libs/SearchParser/autocompleteParser.js src/libs/SearchParser/autocompleteParser.peggy src/libs/SearchParser/baseRules.peggy && ./scripts/parser-workletization.sh src/libs/SearchParser/autocompleteParser.js",

.

Also wrap the parse(input) call in parseForLiveMarkdown with the same parser-error boundary that parseForAutocomplete already has. If autocomplete parsing fails while decorating the Search input, return an empty markdown range list instead of letting a parser implementation error take down /search.

For regression coverage, add a focused Search autocomplete test that exercises parseForLiveMarkdown through malformed/edge Search text and asserts it returns ranges or an empty array without throwing. The web build should also no longer contain _classCallCheck_autocompleteParser / Cannot call a class as a function entries mapped to src/libs/SearchParser/autocompleteParser.js after regenerating the parser.

What alternative solutions did you explore? (Optional)

I considered the cached L1 theory around NumberFormatUtils, but the verified source-map evidence points to autocompleteParser.js, not NumberFormatUtils. Locally, NumberFormatUtils constructs the memoized formatter with new at

App/src/libs/NumberFormatUtils/index.ts

Lines 22 to 32 in 6ea10e7

	function createFormatter(locale: Locale | undefined, options?: Intl.NumberFormatOptions): Intl.NumberFormat {
	try {
	return new MemoizedNumberFormat(locale ?? CONST.LOCALES.DEFAULT, options);
	} catch (e) {
	if (e instanceof RangeError && options && 'currency' in options) {
	const currency = String(options.currency ?? '');
	if (!warnedMalformedCurrencies.has(currency)) {
	warnedMalformedCurrencies.add(currency);
	Log.warn('NumberFormatUtils: malformed currency code, falling back to USD', {currency: options.currency});
	}
	return new MemoizedNumberFormat(locale ?? CONST.LOCALES.DEFAULT, {...options, currency: CONST.CURRENCY.USD});

, and the shared memoizer preserves constructor calls via new.target at

App/src/libs/memoize/index.ts

Lines 59 to 80 in 6ea10e7

	// Detect if memoized function was called with `new` keyword. If so we need to call the original function as constructor.
	const constructable = !!new.target;
	// If skipCache is set, check if we should skip the cache
	if (options.skipCache?.(args)) {
	const fnTimeStart = performance.now();
	const result = (constructable ? new (fn as Constructable)(...args) : (fn as Callable)(...args)) as IsomorphicReturnType<Fn>;
	statsEntry.trackTime('processingTime', fnTimeStart);
	statsEntry.track('didHit', false);
	return result;
	}
	const truncatedArgs = truncateArgs(args, options.maxArgs);
	const key = options.transformKey ? options.transformKey(truncatedArgs) : (truncatedArgs as Key);
	const cached = cache.getSet(key, () => {
	const fnTimeStart = performance.now();
	const result = (constructable ? new (fn as Constructable)(...args) : (fn as Callable)(...args)) as IsomorphicReturnType<Fn>;

. Changing the memoizer or chart number formatting would not remove the _classCallCheck_autocompleteParserJs5 helper that Sentry is reporting.

A catch-only fix in parseForLiveMarkdown would reduce crashes, but it would leave the bad class workletization in the shipped Search bundle. Removing the class shim fixes the actual source-map-backed class-call path, and the parser boundary prevents future autocomplete parser errors from escaping the Search input renderer.