[Exploratory] Tags - Validation error appears on only one multilevel tag when tags are disabled

[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.32-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: #94105
Email or phone of affected tester (no customers): biruknew45+gjkgh5@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Web, android
App Component: Chat Report View

Action Performed:

Preconditions:
Workspace has multilevel tags (https://github.com/user-attachments/files/29099944/Bug7184721_1781793315333.Independent.-.Multi.Level.tags.csv)

1. Go to staging.new.expensify.com
2. Go to workspace chat and create an expense
3. Select a tag for all multilevel tags
4. Go to workspace settings > More features and disable tags
5. Go back to workspace chat and open the expense

Expected Result:

The "no longer valid" error should appear on all multilevel tags.

Actual Result:

The "no longer valid" error appears on only one tag.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7203748_1783598686319.bandicam_2026-07-09_14-56-30-435.mp4

View all open jobs on GitHub

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

[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/82e5a538c2e70a3b4bc3193f7a9153bd04b076b0cfbdd50bcce785684656fceb

[mukhrr]

This was discussed here #94105 (comment). @lakchote do we want to fix this issue?

[lakchote]

I don’t think we should fix this. The backend returns one tagOutOfPolicy violation for the first invalid tag level, and App intentionally mirrors that behavior. The remaining levels still show the delete confirmation, which clears the full multi-level tag. I’d close this as expected behavior; showing an error on every level would be a separate product decision. cc @trjExpensify

Context:

• Auth returns immediately when it finds the first invalid tag level: https://github.com/Expensify/Auth/blob/5fb5de9b2bd6528fac50abd9f36db250d2b5d70e/auth/lib/Violations.cpp#L1261-L1268
• App deliberately stops after creating the first matching violation:

  App/src/libs/Violations/ViolationsUtils.ts

  Lines 218 to 231 in 88a0e4a

  	if (!isTagInPolicy) {
  	newTransactionViolations.push({
  	name: CONST.VIOLATIONS.TAG_OUT_OF_POLICY,
  	type: CONST.VIOLATION_TYPES.VIOLATION,
  	showInReview: true,
  	data: {
  	tagName: policyTagKeys.at(i),
  	},
  	});
  	hasInvalidTag = true;
  	// The backend emits a single tagOutOfPolicy for the whole multi-level tag (labeled with the first
  	// out-of-policy level), so stop here to match it - flagging every level would flash extra errors on
  	// the other level rows that vanish once the backend response syncs.
  	break;

• The regression test explicitly expects a single violation on the first stale level:

  App/tests/unit/ViolationUtilsTest.ts

  Lines 1827 to 1846 in 88a0e4a

  	it('should return a single tagOutOfPolicy for the first stale level when the Tags feature is disabled and no tags are enabled', () => {
  	// The backend emits one tagOutOfPolicy for the whole multi-level tag (the first out-of-policy level by
  	// orderWeight), so the optimistic recompute must match it instead of flagging every level.
  	policyTags.Department.tags.Accounting.enabled = false;
  	policyTags.Region.tags.Africa.enabled = false;
  	policyTags.Project.tags.Project1.enabled = false;
  	transaction.tag = 'Africa:Accounting:Project1';
  	const result = ViolationsUtils.getViolationsOnyxData({
  	updatedTransaction: transaction,
  	transactionViolations,
  	policy,
  	policyTagList: policyTags,
  	policyCategories,
  	hasDependentTags: false,
  	isInvoiceTransaction: false,
  	});
  	// Region has the lowest orderWeight (1), so it is the level the violation is reported on.
  	expect(result.value).toEqual([{...tagOutOfPolicyViolation, data: {tagName: 'Region'}}]);

• We also explicitly agreed in Fixed money request optimistic violations #94105 that the second-level tag not showing the error still makes sense: Fixed money request optimistic violations #94105 (comment)

Closing it in the meantime.