[$250] [Due for payment 2026-04-28] Tag Becomes Invalid After Saving — Leading “:” Added to Tag Value

[m-natarajan]

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.3.7-3
Reproducible in staging?: Needs Reproduction (Unable to reproduce)
Reproducible in production?: Needs Reproduction
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Expensify/Expensify Issue URL:
Issue reported by: @abbagail
Slack conversation (hyperlinked to channel name): #Expensify Bugs

Action Performed:

1. Open an expense
2. Edit the Tag field
3. Save the tag
4. Submit the expense report
5. Review the expense for violations

Expected Result:

The selected tag should remain valid after saving and submitting.
No violation should be triggered.

Actual Result:

A violation is shown:
ND: “Departments are no longer valid”
Classic: “Tag no longer valid”, extra : at the start of the invalid tag.

Workaround:

Unknown

Platforms:

Select the officially supported platforms where the issue was reproduced:

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

Screenshots/Videos

The screenshots for the issue is in slack thread

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @mallenexpensify

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022049236099718576730
• Upwork Job ID: 2049236099718576730
• Last Price Increase: 2026-04-28

[melvin-bot]

Triggered auto assignment to @stephanieelliott (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]

Triggered auto assignment to @stephanieelliott (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.

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[MelvinBot]

This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989

[WeberG619]

Proposal

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

When a user edits and saves a tag on an expense in a workspace with multiple tag levels, a leading : is prepended to the tag value (e.g., :Engineering instead of Engineering). This corrupted string then triggers false "tag no longer valid" violations on the Classic side.

What is the root cause of that problem?

The root cause is in insertTagIntoTransactionTagsString at src/libs/IOUUtils.ts (line 276):

const tagArray = getTagArrayFromName(transactionTags);

getTagArrayFromName (in src/libs/TransactionUtils/index.ts:1275) splits by CONST.COLON. When transactionTags is an empty string "", "".split(":") returns [""] — an array with one empty string element, not an empty array.

Step-by-step trace:

1. User opens an expense with no tags set yet (transactionTags = "")
2. User selects a tag for the second tag level (e.g., tagIndex = 1)
3. getTagArrayFromName("") returns [""] (one empty element)
4. tagArray[1] = "Engineering" produces ["", "Engineering"]
5. The trailing-trim loop doesn't remove anything because the last element ("Engineering") is truthy
6. ["", "Engineering"].join(":") produces ":Engineering" — the leading colon

This causes violations because:

• getTagArrayFromName(":Engineering") returns ["", "Engineering"]
• In ViolationsUtils.ts, tags.includes('') is true, triggering ALL_TAG_LEVELS_REQUIRED
• For independent tags, !!selectedTags.at(0) is false for the empty string, triggering SOME_TAG_LEVELS_REQUIRED

The dependent tags path does NOT have this bug because IOURequestStepTag.tsx line 100 correctly guards:

const tagParts = transactionTag ? getTagArrayFromName(transactionTag) : [];

This pattern avoids the phantom empty element by checking for empty/falsy transactionTag before splitting.

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

Apply the same guard pattern already used in the dependent tags path:

File: src/libs/IOUUtils.ts — insertTagIntoTransactionTagsString function

// Change line 276 from:
const tagArray = getTagArrayFromName(transactionTags);

// To:
const tagArray = transactionTags ? getTagArrayFromName(transactionTags) : [];

This is a one-line fix that follows the existing convention in the codebase.

Optionally, fill sparse array slots to handle the case where tagIndex > tagArray.length:

for (let i = 0; i < tagArray.length; i++) {
    if (tagArray[i] === undefined) {
        tagArray[i] = '';
    }
}

Why NOT modify getTagArrayFromName: That function has a sync requirement with TransactionUtils.php (noted in the source with a prominent warning comment). Changing its behavior could break server-side compatibility.

Files to change:

• src/libs/IOUUtils.ts — Guard empty transactionTags in insertTagIntoTransactionTagsString
• Test file for insertTagIntoTransactionTagsString — Add test case for empty transactionTags with tagIndex > 0

What alternative solutions did you explore? (Optional)

• Considered modifying getTagArrayFromName to return [] for empty strings, but the function has a server-sync requirement (TransactionUtils.php) and changing it could break other callers.
• Considered adding a trim/filter after getTagArrayFromName, but the truthiness guard is cleaner and matches the existing pattern in IOURequestStepTag.tsx.

[WeberG619]

PR submitted: #82029

The fix guards getTagArrayFromName with an empty-string check in insertTagIntoTransactionTagsString, matching the existing pattern in IOURequestStepTag.tsx. When transactionTags is empty, uses [] instead of [""].split(":") which produced the leading colon.