[$250] Missing category error shown briefly, then re-appears with a whisper message

[nlemma]

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.2.79-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: #76176
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: MacBook Air 15.6.1 Chrome, iPhone 15 iOS 26.1
App Component: Chat Report View

Action Performed:

1. Sign in to ND with a new user
2. Create a workspace with Categories enabled
3. Create a manual expense without category in the workspace chat
4. Observe the expense preview

Expected Result:

"Missing category" violation appears after creating expense and does not disappear

Actual Result:

"Missing category" violation briefly appears after creating expense, then disappears, then re-appears along with the Concierge whisper message

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7031653_1765928784482.Missing_category_re-appears.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022001416678901751153
• Upwork Job ID: 2001416678901751153
• Last Price Increase: 2025-12-17

Issue Owner

Current Issue Owner: @getusha

[melvin-bot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

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

[melvin-bot]

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

[etCoderDysto]

BE issue, RequestMoney API request is returning the transactionViolation with null value

[marufsharifi]

🚨 Edited by proposal-police: This proposal was edited at 2025-12-19 16:42:22 UTC.

Proposal

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

When creating a manual expense without a category in a workspace with Categories enabled, the "Missing category" violation (red dot + message) briefly appears after expense creation, then disappears, and then re-appears when the Concierge whisper message( ACTIONABLE_TRACK_EXPENSE_WHISPER) is added.

What is the root cause of that problem?

The transaction preview banner visibility is controlled by shouldShowRBR (red dot) and RBRMessage (error text) in TransactionPreviewUtils.ts. These values are computed based on the violations array from Onyx in the functions createTransactionPreviewConditionals() and getTransactionPreviewTextAndTranslationPaths().

The issue occurs because:

1. Upon expense creation, an optimistic render may briefly show the violation
2. The backend API response returns transactionViolations_<id>: null, which clears any optimistic violation data
3. The frontend (in TransactionPreviewContent.tsx) has no client-side validation using policy.requiresCategory to provide stable feedback
4. The violation only re-appears when proper server violations arrive (with the Concierge whisper)

The app relies too heavily on server-generated violations without local policy-based validation as a fallback.

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

Add client-side validation using policy.requiresCategory to ensure the violation banner displays immediately and persistently, regardless of backend response timing.

1. Changes in TransactionPreviewUtils.ts:

In createTransactionPreviewConditionals function - add policy parameter and client-side check:

 function createTransactionPreviewConditionals({

+    const policyRequiresCategory = policy?.requiresCategory ?? false;
+    const isCategoryRequiredButMissing = policyRequiresCategory && isCategoryMissing(category);

     const hasAnyViolations =
         // ... existing conditions ...
         || (isDistanceRequest(...) && ...)
+        || isCategoryRequiredButMissing;

     const hasErrorOrOnHold =
         // ... existing conditions ...
+        || isCategoryRequiredButMissing;

     return {
         // ... existing returns
+        isCategoryRequiredButMissing,
     };
 }

In getTransactionPreviewTextAndTranslationPaths function - add parameters and message fallback:

 function getTransactionPreviewTextAndTranslationPaths({
     // ... existing params
+    isCategoryRequiredButMissing,
 }: {
     // ... existing types
+    isCategoryRequiredButMissing: boolean;
 }) {
     // ... after hasFieldErrors block ...

+    if (isCategoryRequiredButMissing && (!RBRMessage || RBRMessage.text === '')) {
+        RBRMessage = {translationPath: 'violations.missingCategory'};
+    }

     // ... rest unchanged
 }

2. Changes in TransactionPreviewContent.tsx

-const {shouldShowRBR, shouldShowMerchant, shouldShowSplitShare, shouldShowTag, shouldShowCategory, shouldShowSkeleton, shouldShowDescription} = conditionals;
+const {shouldShowRBR, shouldShowMerchant, shouldShowSplitShare, shouldShowTag, shouldShowCategory, shouldShowSkeleton, shouldShowDescription, isCategoryRequiredButMissing} = conditionals;

 const previewText = useMemo(
     () => getTransactionPreviewTextAndTranslationPaths({
         ...transactionPreviewCommonArguments,
         shouldShowRBR,
         violationMessage,
         reportActions,
         currentUserEmail: currentUserDetails.email ?? '',
         currentUserAccountID: currentUserDetails.accountID,
         originalTransaction,
+        isCategoryRequiredButMissing,
     }),
-    [transactionPreviewCommonArguments, shouldShowRBR, violationMessage, reportActions, currentUserDetails.email, currentUserDetails.accountID, originalTransaction],
+    [transactionPreviewCommonArguments, shouldShowRBR, violationMessage, reportActions, currentUserDetails.email, currentUserDetails.accountID, originalTransaction, isCategoryRequiredButMissing],
 );

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

• Manual expense in required-category workspace + no category → banner visible immediately and remains after whisper
• Same scenario with valid category → no banner
• Non-required category workspace → no banner even if category empty
• Edit expense: remove required category → banner appears instantly

What alternative solutions did you explore? (Optional)

The backend sometimes returns transactionViolations: null in the initial response, which clears optimistic data. This client-side fix ensures consistent behavior regardless.

[mavrickdeveloper]

Instead of a workaround , imo:

• Issue is caused by the RequestMoney API returning transactionViolations: null in the initial response. This clears the client's optimistic violations before the server computes and sends the real ones via Pusher
• Best approach would be to include the transactionViolations key in the API response if violations haven't been computed yet. This will preserve the client's optimistic violations until the server pushes the real ones

Addressing this at BE is a more solid path

[ChinmayKarnik]

Proposal

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

Transaction violations (e.g., "missing category") flicker/disappear briefly when creating a manual expense without a category in a workspace with categories enabled. The violation shows optimistically, then hides momentarily before reappearing, creating a poor user experience.

What is the root cause of that problem?

• Optimistic Update: Client immediately sets transactionViolations based on local computation (e.g., missing category if none selected).
• HTTP Response: Backend sends response.onyxData with transactionViolations: null because violations are computed asynchronously on the server.
• Pusher Update: Backend later sends correct violations via real-time Pusher events.
• Result: UI shows violation → hides (null) → shows again (Pusher), causing flicker.

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

Implement a frontend "Optimistic Data Preservation" layer to prevent premature clearing of optimistically set data when the backend sends null due to async computation.

• Create a new module (/src/libs/OptimisticDataPreservation.ts) with configurable rules for keys/commands that should preserve optimistic values (e.g., transactionViolations_* on REQUEST_MONEY).
• Modify applyHTTPSOnyxUpdates in OnyxUpdates.ts to filter response.onyxData using these rules, skipping updates that would nullify existing optimistic data.
• Only requests/keys with explicit preservation rules will be affected. All other updates will be applied as usual, so there is no risk of preserving stale optimistic data for unrelated flows.
• This is a foolproof method that ensures no other flows are affected and only applies to explicitly defined cases—making it both safe and easily reversible if/when the backend is updated.

Example rule for transaction violations

{
  keyPattern: /^transactionViolations_/,
  commands: [WRITE_COMMANDS.REQUEST_MONEY],
  condition: (currentValue, newValue) =>
    currentValue && currentValue.length > 0 && (!newValue || newValue.length === 0),
}

This rule means: if the backend tries to set a transactionViolations_* key to null or [] for a REQUEST_MONEY command, but the current value is a non-empty array (from optimistic update), we skip the update and preserve the optimistic value until the backend sends a real value (e.g., via Pusher).

Example pseudo-code for the preservation logic

function preserveOptimisticData(onyxData, request) {
  return onyxData.filter(update => {
    if (matchesRule(update.key, request.command)) {
      currentValue = getCurrentOnyxValue(update.key);
      if (shouldPreserve(currentValue, update.value)) {
        return false; // Skip nullifying update
      }
    }
    return true; // Apply update
  });
}

This approach is general and extensible—rules can be added for other async-computed fields without core changes.

While a backend solution would be ideal for eliminating the flicker at the source (as @mavrickdeveloper suggested), this frontend preservation layer is a foolproof method that ensures no other flows are affected and only applies to explicitly defined cases—making it both safe and easily reversible if/when the backend is updated.

What alternative solutions did you explore?

• Backend Fix: Compute violations synchronously in API responses.
  @mavrickdeveloper previously suggested this approach, and it would indeed solve the flicker at the source.However, given the current performance and architectural constraints discussed in the thread, a frontend solution is proposed as a practical step to address the user experience in the short term. This approach allows the backend to continue async computation as needed. If backend changes become feasible in the future, this layer can be easily adjusted or removed.
• UI-Level Debouncing: Delay violation UI updates. Rejected as it masks the issue rather than solving data flow.
• Direct Command Checks in HTTPS Layer: Inline if-statements for specific commands. Rejected for maintainability—our proposed layer provides cleaner separation.

[melvin-bot]

📣 @ChinmayKarnik! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:

1. Make sure you've read and understood the contributing guidelines.
2. Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
3. Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
4. Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
   
   Format:

Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>