Rules - Inconsistent setting of a rule when offline editing

[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: v9.4.27-1
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: #94696
Email or phone of affected tester (no customers): applausetester+ag110626ec@applause.expensifail.com
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11/ Chrome, Samsung S23FE/ Android 16, iPhone 13 Mini/ iOS 26.5
App Component: Workspace Settings

Action Performed:

Prerequisites:
Use a workspace with Rules enabled (More features → Rules).
Enable rulesRevamp beta on the test account: Onyx.merge('betas', ['rulesRevamp'])
Enable Attendee tracking

1. Navigate to https://staging.new.expensify.com/
2. Log in with any Expensifail account as a workspace admin
3. Go to workspace settings > Rules > Require fields tab > Create a rule
4. Go offline
5. Go to any rule details
6. Deselect Attendees and select Description
7. Click Save rule
8. Go back to the edited rule details

Expected Result:

The Description checkbox is selected, while the Attendees checkbox remains cleared.
The text in the Rule column shows only "Require description".

Actual Result:

The two checkboxes are selected in the rule details.
The text in the Rule column shows "Require description, require attendees".

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7198964_1783114264791.inconsistent_setting.mp4

View all open jobs on GitHub

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

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/9d74a00479df86b5ab05f22db1a8e557e0e1a163c5d5ac9c2750de581653bdba

[melvin-bot]

@luacmartins recently merged #94696, but they are OOO right now, so I'll auto-assign someone else.

[melvin-bot]

Triggered auto assignment to @grgia (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

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

Proposal

What is the root cause of that problem?

When you deselect a Require-fields field offline (e.g. Attendees), the optimistic Onyx update writes the field's original value back instead of the new "off" value, so the field is never actually turned off offline.

The save flow (RequireFieldsRulePageBase → saveRequireFieldsRule → setPolicyCategory*Required) toggles each field via setPolicyCategoryAttendeesRequired / setPolicyCategoryDescriptionRequired in src/libs/actions/Policy/Category.ts. In the removal branch the optimistic data is:

// isRemoving === true (deselect)
{
    pendingAction: RED_BRICK_ROAD_PENDING_ACTION.UPDATE,
    pendingFields: { areAttendeesRequired: RED_BRICK_ROAD_PENDING_ACTION.DELETE },
    areAttendeesRequired: originalAreAttendeesRequired,   // ⬅️ stays `true` offline
}

This is applied with Onyx.METHOD.MERGE. The only real boolean it writes is set back to the old value (originalAreAttendeesRequired), so MERGE changes nothing. The pendingFields.<field>: DELETE marker is just red-brick-road metadata — it does not flip the boolean. The display reads the raw boolean (!!category.areAttendeesRequired in RequireFieldsRulesUtils.ts), so the deselected field still shows as required. Meanwhile the newly selected field goes through the non-removing branch and correctly writes true — producing the "both selected" result the tester saw.

Only the successData (which correctly sets the field to false) fixes it, and that never runs offline.

Offending lines:

• Attendees: Category.ts:1826 — areAttendeesRequired: originalAreAttendeesRequired
• Description: Category.ts:434 — areCommentsRequired: originalAreCommentsRequired

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

In the isRemoving branch of both setters, make the optimistic value reflect the removed state instead of the original value, so the MERGE actually turns the field off offline (matching what successData already writes):

• Category.ts:1826 → set areAttendeesRequired: false (equivalently, the areAttendeesRequired arg, which is already false in this branch).
• Category.ts:434 → set areCommentsRequired: false.

The failureData branches already restore the original values on rollback, so no change is needed there.

Investigation details, confidence & related issue

Confidence: High. The path is fully traced UI→optimistic write, the Onyx representation is confirmed (individual booleans areAttendeesRequired / areCommentsRequired on each policyCategories_<policyID> entry, not a list), and the successData (which sets the field to false) proves false is the intended value.

Alternative considered: if the design intended a "pending deletion" grey-out (row shown but marked pending) rather than immediate removal, the display layer in RequireFieldsRulesUtils.ts would instead need to honor pendingFields.<field> === DELETE. But for the reported symptom, optimistically writing false is the minimal correct fix.

Latent same pattern: the receipt-threshold removal helper has the same shape (maxAmountNoReceipt: originalMaxAmountNoReceipt, ~Category.ts:570), but it's masked because its display check is !== null. Worth fixing alongside for consistency.

Possibly related: #95353 ("Rules - Crossed-out rule after offline edit") is in the same offline Require-fields flow and likely stems from the same pendingFields: DELETE marker rendering the row as a pending-delete. Worth checking together.

Introduced by #94696.

---

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