Rules - Receipt require tooltip appears for the second time after dismissal

[applause-bot]

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.4.43-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: #95312
Email or phone of affected tester (no customers): applausetester+ssndjois2jd1@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.5 / Chrome
App Component: Workspace Settings

Action Performed:

Precondition:

• Log in with Expensifail account.
• Enable Rules.

1. Go to staging.new.expensify.com
2. Go to workspace settings > Rules > Field requirements.
3. Click Create field requirement rule.
4. Select a category.
5. Select Require for Description, Receipt and Itemized receipt.
6. Click X on the tooltip.
7. Click Save rule.
8. Click Add rule > Field requirements.
9. Repeat Step 4 to 5.

Expected Result:

Receipt require tooltip will not appear for the second time after dismissal.

Actual Result:

Receipt require tooltip appears for the second time after dismissal.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7214961_1784758422091.2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7214961

Issue Owner

Current Issue Owner: @Krishna2323

[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/bd81833c1059816cc4b0d65a61d44ed1770e9aa6d00c27098f92c088e859b78f

[melvin-bot]

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

[melvin-bot]

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

[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.

[MelvinBot]

Issue Analysis

Root Cause: The coupling tooltip's "dismissed" flag is stored only in per-instance React useState, so it never survives leaving the rule page. In FieldRequirementSettingRow.tsx:57 the dismissal lives in dismissedCouplingTooltipKey local state and gates display at line 62. When you do Add rule → Field requirements again, a fresh RequireFieldsRulePageBase mounts new rows and that state resets to undefined, so re-triggering the same coupling shows the tooltip again. Nothing is written to Onyx/NVP, so there is no persistence.

This is an educational (one-time) tooltip — it reuses the product-training styling, Lightbulb icon and PRODUCT_TRAINING.TOOLTIP Sentry label (lines 79-86) — but was hand-rolled and skips the persistence layer the other product-training tooltips use.

Recommended Fix: Persist dismissal through the existing product-training NVP instead of local state:

1. Add a name to CONST.PRODUCT_TRAINING_TOOLTIP_NAMES (e.g. REQUIRE_FIELDS_RECEIPT_COUPLING).
2. In FieldRequirementSettingRow.tsx, drop the useState and instead read ONYXKEYS.NVP_DISMISSED_PRODUCT_TRAINING (via isProductTrainingElementDismissed in TooltipUtils.ts:5) to compute shouldDisplayCouplingTooltip, and have hideCouplingTooltip call dismissProductTraining(...) so the dismissal is saved server-side and survives remounts/navigation/sessions.

The fuller/canonical alternative is to register the tooltip in ProductTrainingContext/TOOLTIPS.ts and drive it via useProductTrainingContext, matching every other educational tooltip in the app.

⚠️ Lifting the flag into RequireFieldsRulePageBase or React context would only fix reappearance within a single navigation session — it would still reset on reload. The expected behavior ("once dismissed, don't show again") requires the NVP.

Investigation details

Trigger: getRequireFieldsFieldCouplingTooltipKey returns a key when a field's control is coupling-disabled and the user directly toggled the paired field this session (couplingInteractionFields). Requiring Itemized receipt forces Receipt to Require and locks it → receiptDisabledWhenItemizedRequired. Because couplingInteractionFields is reset per page, the same key re-fires on every new rule.

Why it reappears (data flow):

1. New rule page mounts → couplingInteractionFields/touchedFields reset to empty.
2. User re-selects Require on Receipt/Itemized → tooltip key computed → shouldDisplayCouplingTooltip = true.
3. Click X → hideCouplingTooltip sets local dismissedCouplingTooltipKey only — no Onyx write.
4. Save → Add rule again → component remounts → dismissedCouplingTooltipKey === undefined → tooltip shows again.

Confidence: High — deterministic client-side state-lifecycle bug, provable from code; no logs needed.

Introduced by PR #95312 (feature is behind the rulesRevamp beta, so this is new-feature-only, consistent with "N/A in production").

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/96795) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[situchan]

behind beta, not blocker.

This was reported here

And it shows every time this page is re-focused.

cc: @Krishna2323