[$250] Workspace - Inserting number into policy text crashes platform

[izarutskaya]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.77-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @mukhrr
Slack conversation (hyperlinked to channel name): #xpensify_open_source

Action Performed:

1. Go to https://staging.new.expensify.com/
2. Create a workspace
3. Go to WS settings -> Overview
4. Click policy text
5. Insert any number instead of text
6. Wait for a while

Expected Result:

Number is saved as text and no crash

Actual Result:

Platform crashes with Refresh button

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Recording.3769.mp4

REC-20260519100303.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056704816794686334
• Upwork Job ID: 2056704816794686334
• Last Price Increase: 2026-05-19

Issue Owner

Current Issue Owner: @Valforte

[MelvinBot]

Proposal

What is the root cause of that problem?

When a user saves a purely numeric value (e.g. 123) as the policy text (custom rules), the backend may return customRules as a number type (123) instead of a string ("123") in the API response or Pusher update. Onyx merges this number directly into the policy object, overwriting the optimistic string value.

The crash then occurs in WorkspaceOverviewPage.tsx:217 where StringUtils.isEmptyString(policy?.customRules ?? '') is called. Since customRules is a number (not null/undefined), the ?? '' fallback does not activate, and StringUtils.isEmptyString calls .replaceAll() on a number — which throws a TypeError and triggers the error boundary (crash/"Refresh" screen).

A second crash path exists in RulesCustomPage.tsx:36 where Parser.htmlToMarkdown(policy?.customRules ?? '') would similarly crash calling .match() on a number.

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

Coerce customRules to a string at the consumption points to guard against unexpected backend types:

1. In WorkspaceOverviewPage.tsx:217: Change policy?.customRules ?? '' to String(policy?.customRules ?? '').
2. In RulesCustomPage.tsx:36: Change policy?.customRules ?? '' to String(policy?.customRules ?? '').

This ensures both pages are resilient regardless of the type returned by the backend.

What alternative solutions did you explore? (Optional)

An alternative would be to fix the backend to always return customRules as a string. However, adding frontend coercion is the standard defensive approach for Onyx data that comes from API responses, and protects against regressions from any data source (API response, Pusher, etc.).

Investigation details

Evidence chain:

• The optimistic update in Policy.ts:6050 correctly stores a string from getParsedComment()
• The success/failure Onyx data does not re-set customRules, so the value from the backend API response merge is what persists
• StringUtils.isEmptyString has signature (value: string): boolean and immediately calls value.replaceAll() — no runtime type check
• The ?? operator only catches null/undefined, not numbers, so a numeric customRules value passes through unchanged
• The issue description shows the crash happens "after waiting" — consistent with the backend response arriving and overwriting the optimistic string

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 11:59:02 UTC.

Proposal

What is the root cause of that problem?

The crash happens on the Workspace Overview page (…/workspaces/<policyID>/overview, matching the screenshot URL) once the UpdateCustomRules server response merges into Onyx.

Step-by-step:

1. The user types 123 into the Policy text editor and submits. updateCustomRules runs the optimistic update with parsedCustomRules = ReportUtils.getParsedComment("123") — still a string — and Navigation.goBack() returns to the Overview (Policy.ts#L6038-L6092).

2. While the user "waits for a while", the API.write response's response.onyxData is applied on top of the optimistic data (Middleware). For a purely numeric input the server's JSON returns customRules as a JS number (the Policy.customRules declaration at types/onyx/Policy.ts#L2214 is string?, so there is no runtime guard — Onyx writes whatever JSON shape arrives).

3. The next Overview render hits WorkspaceOverviewPage.tsx#L217:

   const hasCustomRulesText = !StringUtils.isEmptyString(policy?.customRules ?? '');

   Because policy.customRules is now 123, ?? '' does not substitute (only null/undefined would). isEmptyString immediately calls value.replaceAll('', PLACEHOLDER) (StringUtils/index.ts#L21-L40) which throws TypeError: v.replaceAll is not a function because numbers have no replaceAll. The ErrorBoundary catches it and the page is replaced with the generic "Uh-oh, something went wrong" screen the reporter screenshotted.

Verified locally in node against the App's own expensify-common: (123).replaceAll('a','b') throws v.replaceAll is not a function, and ExpensiMark.htmlToMarkdown(123) throws generatedMarkdown.match is not a function — i.e. the same shape crashes downstream too.

The same hazard exists at two sibling read sites that will reproduce the crash once customRules is numeric:

• RulesCustomPage.tsx#L36 — Parser.htmlToMarkdown(policy?.customRules ?? '') blows up when the user reopens the editor.
• PolicyUtils.ts#L767 — policy.customRules.trim().length blows up in hasConfiguredRules, which is consumed by the Getting Started checklist (useGettingStartedItems.ts#L147).

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

Coerce customRules to a string at every read site before calling a string method on it. The Overview crash dies with this one-line change:

-    const hasCustomRulesText = !StringUtils.isEmptyString(policy?.customRules ?? '');
+    const hasCustomRulesText = !StringUtils.isEmptyString(String(policy?.customRules ?? ''));

Apply the same String(policy?.customRules ?? '') coercion at the two sibling sites that crash on the next page-load with the bad value:

-    const [customRulesValue, setCustomRulesValue] = useState(() => Parser.htmlToMarkdown(policy?.customRules ?? ''));
+    const [customRulesValue, setCustomRulesValue] = useState(() => Parser.htmlToMarkdown(String(policy?.customRules ?? '')));

And in PolicyUtils.hasConfiguredRules, swap policy.customRules.trim().length > 0 for String(policy.customRules).trim().length > 0. Also pass title={String(policy?.customRules ?? '')} at WorkspaceOverviewPage.tsx#L952 so the MenuItem title prop honors its string? contract (runtime is fine — template-literal interpolation in processedTitle already coerces — but the cleanup matches the type and silences future type-narrowing changes).

What alternative solutions did you explore? (Optional)

• Defend inside StringUtils.isEmptyString by adding String(value) at the top. Rejected — it widens the helper's contract beyond string and just relocates the same hazard. Other callers that legitimately pass a string get a slower path, and other crash sites (Parser.htmlToMarkdown, .trim()) still need their own guards.
• Normalize customRules once at the action level in updateCustomRules's optimistic data. Rejected — the optimistic value is already a string (getParsedComment returns string). The non-string only appears via response.onyxData after the round-trip, which the action doesn't control.
• Add a memoized selector on the policy Onyx key that coerces customRules. Rejected — over-engineered for a single field; the String(...) guard at the three read sites is one short line each and surfaces the intent right where it matters.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-19 11:59:51 UTC.

Proposal

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

Entering a number-only value in Workspace settings > Overview > Expense policy > Policy text crashes the app after the value is saved. The digits should be treated as policy text and rendered normally.

What is the root cause of that problem?

"Policy text" is the workspace custom rules field, not the workspace description field. In src/languages/en.ts, workspace.rules.customRules.policyText is the label used by WorkspaceOverviewPage for policy.customRules.

Policy.customRules is typed as a string, but a numeric-only policy text value can come back from the API/Onyx as a JavaScript number. The current code only uses ?? '', which handles nullish values but does not coerce non-null values to strings.

That numeric value can then hit string-only paths:

• WorkspaceOverviewPage computes hasCustomRulesText with StringUtils.isEmptyString(policy?.customRules ?? ''). If customRules is 23, StringUtils.isEmptyString calls value.replaceAll(...) on a number and throws TypeError: value.replaceAll is not a function, causing the Refresh crash.
• The same page renders the Policy text menu item with title={policy?.customRules ?? ''} and shouldRenderAsHTML, so this display path should also receive a string.
• RulesCustomPage initializes the editor with Parser.htmlToMarkdown(policy?.customRules ?? ''); that parser path also expects a string and can crash if the numeric Onyx value is present when opening the editor.

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

Normalize workspace policy text/custom rules to a string before it enters parser, string utility, render, comparison, or API boundaries.

Concretely:

1. Add a small helper for this field, for example getPolicyCustomRulesText(value), that returns '' for null/undefined and String(value) otherwise.
2. In WorkspaceOverviewPage, compute a normalized customRulesText once from policy?.customRules and use it for hasCustomRulesText, the Policy text menu item title, and any other custom-rules display checks.
3. In RulesCustomPage, pass the normalized value to Parser.htmlToMarkdown and pass the normalized current value into updateCustomRules.
4. In updateCustomRules, normalize both the submitted value and the current value before calling ReportUtils.getParsedComment, comparing old/new values, writing optimistic/failure Onyx data, and sending the UPDATE_CUSTOM_RULES description parameter.
5. Add regression coverage for a policy whose customRules value is numeric at runtime, verifying the Overview page does not crash, the Policy text row renders the digits, and the editor opens with the digits as text.

This keeps the fix scoped to the field that backs the reported "Policy text" UI while still protecting every App-side read/write path for that field.

What alternative solutions did you explore? (Optional)

We could coerce all non-string inputs inside shared helpers such as StringUtils.isEmptyString and Parser.htmlToMarkdown/htmlToText. That would prevent this crash class more broadly, but it also weakens those helpers' string contracts and can hide bad data for unrelated callers. Normalizing at the policy.customRules boundary is safer for this issue.

A backend/API fix that always returns policy text fields as strings would also be useful, but the App should still be defensive because existing persisted or pushed Onyx data can already contain the numeric value.

Comparison branch :- main...KJ21-ENG:KJ21-ENG/91069-policy-text-custom-rules

Proof of working fix :-

1779204431541722.mp4

[mukhrr]

Proposal

What is the root cause of that problem?

When a workspace description or custom rules field is set to a value made up only of digits — e.g. 23 — the backend serializes it back as a JSON number (23), not a string ("23"). The App types Policy['description'] / Policy['customRules'] as string, so nothing coerces it, and every consumer guards it only with ?? '', which substitutes a default only for null/undefined. A numeric 23 passes straight through into shared text utilities that assume a string.

This produces two separate white-screens from the same cause:

1. WorkspaceOverviewPage → StringUtils/index.ts#L21-L31 — isEmptyString(23) → (23).replaceAll → TypeError: value.replaceAll is not a function.
2. RulesCustomPage → RulesCustomPage.tsx#L36 calls Parser.htmlToMarkdown(policy?.customRules ?? '') with 23, and ExpensiMark.htmlToMarkdown does generatedMarkdown.match(...) → (23).match → TypeError: generatedMarkdown.match is not a function.

Both crash through ErrorBoundary, blanking the page. Patching only one call site just moves the crash to the next consumer — the fix has to live at the shared text-utility boundary.

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

Harden the two shared, app-wide text choke points so a non-string (numeric) value can't white-screen the app. Both are typed string and are the single entry points the whole app funnels through, so coercing here fixes this entire class of bug, not just these two pages:

 function isEmptyString(value: string): boolean {
     // ...
     const PLACEHOLDER = '<<KEEP_E100>>';
-    let transformed = value.replaceAll('\uE100', PLACEHOLDER);
+    let transformed = String(value ?? '').replaceAll('\uE100', PLACEHOLDER);

 htmlToMarkdown(htmlString: string, extras?: Extras): string {
-    return super.htmlToMarkdown(htmlString, {
+    return super.htmlToMarkdown(String(htmlString ?? ''), {

The same String(... ?? '') guard is applied to Parser.htmlToText (same wrapper, same exposure). Behavior is identical for every existing string input; a numeric value simply renders as its digits ("23") instead of crashing.

What alternative solutions did you explore? (Optional)

• Cast at the call sites — String(policy?.customRules ?? '') / String(policy?.description ?? '') in RulesCustomPage and WorkspaceOverviewPage. This is exactly the whack-a-mole I hit: fixing WorkspaceOverviewPage alone left RulesCustomPage crashing. There are more readers of these fields, so the shared-utility fix is the robust one.
• Fix at the type/data source — coerce customRules/description to a string when the policy payload is applied to Onyx, or fix ExpensiMark in expensify-common. Correct long-term, but a broader/cross-repo change that still leaves the shared utilities fragile to any other numeric-typed field. I'd treat it as a complementary follow-up, not the primary fix here.

Demo:

REC-20260519200245.mp4

[mukhrr]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

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

[MobileMage]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.