Expense - Description hint shown in duplicate workspace without category hint

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.

---

Version Number: V9.4.84-0
Reproducible in staging?: Yes
Reproducible in production?: N/A - new feature, doesn't exist in prod
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #101072
Email or phone of affected tester (no customers): dreamnitethedragon+vegst@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Redmi note 10s android 13
App Component: Workspace Settings

Action Performed:

1. Launch app
2. Go to workspace settings - enable rules
3. Tap category advertising- description hint - upgrade - enter a hint and save
4. Tap 3 dots and select duplicate workspace
5. In creating duplicate workspace flow, select all and disable rules and complete the flow
6. Open the category advertising and note no description hint row
7. Open workspace chat
8. Try to create an expense selecting category advertising

Expected Result:

In duplicate workspace, description hint must not be shown when there is no hint row in category settings.

Actual Result:

In duplicate workspace, description hint is shown when there is no hint row in category settings.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263037_1789720617674.Screenrecorder-2026-09-18-13-58-47-155.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Julia Ponikarchuk
Bug ID: 7263037

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/bf2a2111282afb76d1f7c8312a39d5f6e06db9ffd0ba8c34e443ca44d9f85641

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #101072

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[melvin-bot]

@mountiny @Ollyws you have been assigned to this deploy blocker because you reviewed the offending PR: #101072

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[MelvinBot]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: Show the category description hint on the expense creation description field (Expensify/App#101072) - by the PR author, approved by @Ollyws and @mountiny (High confidence)
Related Issues: none found

Recommendation: ROLL FORWARD

The new hint is rendered straight from policyCategory.commentHint with no check that the policy's Rules feature is enabled, while everything else in the same form (and the category settings page) gates on arePolicyRulesEnabled. A one-line gate is a smaller, safer change than a revert, and it also lets us fix the identical ungated hint that already exists on the standalone description page in production. If a fix isn't up quickly, reverting #101072 is clean (it only touches one component plus its test) and does unblock the deploy.

Assigned: @Ollyws and @mountiny (approving reviewers) plus the PR author, from the single causing PR.
Labels: No changes. DeployBlockerCash stays (App-side fix); DeployBlocker was never applied.

📋 Detailed Analysis

Evidence

• The reported surface — the description field on the expense confirmation list — only started showing a category hint in this release. On production the file has no hint at all; on staging it does, added solely by Show the category description hint on the expense creation description field #101072.
• Show the category description hint on the expense creation description field #101072 touches exactly two files, one of them being the affected component: src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx.
• The added line reads the hint with no rules gate: DescriptionField.tsx#L58, rendered at #L126-L127.
• Merge date (2026-09-17) matches the 9.4.84 staging build the tester reported, and the PR is on the open deploy checklist.
• Reproducible on staging only; not in production (the confirmation-list hint does not exist there).

Verification

• Affected file: src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx — confirmed present in gh pr view 101072 --json files.
• Same-component sibling logic already gates on rules: MoneyRequestConfirmationList.tsx#L378 passes arePolicyRulesEnabled(policy, policyCategories) into isCategoryDescriptionRequired, which returns false when rules are off. So in the duplicated workspace the description is correctly not required, yet the hint still renders — an internal inconsistency introduced by the new line.
• The category settings page hides the hint row through the same gate: CategorySettingsPage.tsx#L78 and #L335-L347. That is exactly the "no hint row in category settings" the tester saw in step 6.

Root Cause

Duplicating a workspace with Rules unchecked produces a policy with areRulesEnabled: false — Policy.ts#L3520 — while the copied categories are spread wholesale, commentHint included — Policy.ts#L3608-L3609 calling buildOptimisticPolicyWithExistingCategories.

That combination (rules off, category rule data still present) is legitimate and every other consumer tolerates it by checking arePolicyRulesEnabled — see PolicyUtils.ts#L1764-L1778. The new hint does not, so it renders stale rule data the workspace admin can no longer see or edit.

Suggested fix in DescriptionField.tsx, gating line 58 on the flag the component can already derive from its policy prop:

const areRulesEnabled = arePolicyRulesEnabled(policy, policyCategories);
const descriptionHint = areRulesEnabled && categoryState?.category ? (policyCategories?.[categoryState.category]?.commentHint ?? '') : '';

Two follow-ups, both out of scope for unblocking this deploy:

1. The standalone description step has the same ungated read and is already in production: DynamicIOURequestStepDescription.tsx#L189. Reverting Show the category description hint on the expense creation description field #101072 alone would not fix that path, which is the main argument for rolling forward with a shared gate.
2. Workspace duplication copies category rule fields even when Rules isn't selected, unlike the copy-settings path which deliberately filters them (CopyPolicySettings.ts#L242-L251). Worth aligning separately, but the display gate is the correct fix here since a policy can also have rules toggled off after hints were set.

💡 Suggested AI code review rule

This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:

• Rule: CONSISTENCY-18 Gate policy feature data on the feature flag, not on the data being present
• Condition: When rendering or acting on data that belongs to an optional policy feature (category rules such as commentHint / areCommentsRequired / maxExpenseAmount, tags, taxes, distance rates), check the feature flag with arePolicyRulesEnabled / isPolicyFeatureEnabled first. Stale feature data survives on the policy after the feature is turned off or skipped during a workspace duplicate/copy, so presence of the field is not permission to show it.
• Why: The field is still populated while the admin-facing setting is hidden, so users see values nobody can see or edit — exactly what happened here, where the confirmation-list description hint rendered in a duplicated workspace that had Rules disabled.
• Search pattern: rg -n "commentHint|areCommentsRequired|areAttendeesRequired|maxAmountNoReceipt" src/components src/pages and flag any hit in a file that does not also match arePolicyRulesEnabled|isPolicyFeatureEnabled.
• Offending code (❌):

  App/src/components/MoneyRequestConfirmationList/sections/DescriptionField.tsx

  Line 58 in 9023639

  const descriptionHint = categoryState?.category ? (policyCategories?.[categoryState.category]?.commentHint ?? '') : '';

• Correct shape (✅):

  App/src/components/MoneyRequestConfirmationList.tsx

  Line 378 in 9023639

  const isDescriptionRequired = isCategoryDescriptionRequired(policyCategories, iouCategory, arePolicyRulesEnabled(policy, policyCategories));

The full rule file, with the ❌/✅ code inline in App's app-coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.