[$250] Chat - Green dot for inbox not display when message in group come.

[jponikarchuk]

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.40-3
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/folder/13176684/test-cases/41236584?q=TC-3233
Email or phone of affected tester (no customers): crowdtest.expensify+nt1@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Android
App Component: Other

Action Performed:

Pre-condition: 2 devices with 2 account in 1 group

1. Open app both
2. A go to another tab (Eg. Report)
3. B chat in common group of A and B

Expected Result:

At User A, green dot at inbox should be showing.

Actual Result:

Green dot for inbox not display when message in group come.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

screen-20260319-135635-1773921375931.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @abdulrahuman5196

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022034605296062216209
• Upwork Job ID: 2034605296062216209
• Last Price Increase: 2026-03-19

[MelvinBot]

Proposal

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

When User A is on a different tab (e.g., Reports) and User B sends a message in a common group chat, the green dot indicator on the Inbox tab does not appear for User A on Android.

What is the root cause of that problem?

The green dot on the Inbox tab is an "attention required" indicator, not a general unread message indicator. It is driven by brickRoadStatus from the reportAttributes derived value, which only gets set to INFO (green) when requiresAttention returns true for at least one report in the LHN.

The data flow is:

1. NavigationTabBar (src/components/Navigation/NavigationTabBar/index.tsx:74) calls getChatTabBrickRoad(orderedReportIDs, reportAttributes)
2. getChatTabBrickRoad (src/libs/WorkspacesSettingsUtils.ts:44-47) iterates all LHN-visible reports and checks brickRoadStatus from reportAttributes
3. brickRoadStatus is computed in src/libs/actions/OnyxDerived/configs/reportAttributes.ts:252-256 — it's set to INFO only when requiresAttention is true
4. requiresAttention comes from getReasonAndReportActionThatRequiresAttention() (src/libs/ReportUtils.ts:4285-4387), which only returns non-null for: @mentions (isUnreadWithMention), outstanding tasks, expense approval requests, join requests, fraud alerts, and missing invoice bank accounts

A plain new message (without @mention) in a group chat does NOT trigger requiresAttention, so brickRoadStatus remains undefined, and no green dot appears. This is the current design.

The UnreadIndicatorUpdater module — which does count plain unread messages — is a complete no-op on Android (src/libs/UnreadIndicatorUpdater/updateUnread/index.android.ts). On web it updates the browser tab title/favicon, on iOS it sets the Airship badge. Neither path affects the in-app green dot on the tab bar.

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

There are two interpretations of this issue:

Interpretation A — The green dot should show for ANY unread message (product change needed):

If the expected behavior is that the Inbox tab shows a green dot whenever there are unread messages (not just attention-requiring ones), then getChatTabBrickRoad in src/libs/WorkspacesSettingsUtils.ts needs to also check the isUnread attribute from reportAttributes. Currently reportAttributes already computes isUnread for each report (via generateReportAttributes at src/libs/ReportUtils.ts:12762-12798). The fix would be:

In src/libs/WorkspacesSettingsUtils.ts, modify getChatTabBrickRoadReportID to also check for unread reports (not just those with brickRoadStatus). For example, if any report in orderedReportIDs has reportAttributes[reportID]?.isUnread === true and no existing brickRoadStatus, return INFO.

Alternatively, the brickRoadStatus computation in reportAttributes.ts could be extended to include a plain unread check (if isUnread and notification preference is not muted) as a lower-priority INFO status.

Interpretation B — This is working as designed (test case needs updating):

If the green dot is intentionally only for attention-requiring items (mentions, approvals, etc.), then the test case TC-3233 expectation is incorrect and should be updated.

What alternative solutions did you explore? (Optional)

I investigated whether recent PRs could have introduced a regression:

• PR Perf: skip reportAttributes full recompute on initial locale load #83828 (Mar 18) changed reportAttributes to default to incremental mode on startup — this affects performance, not logic
• PR [NO QA] Fix LHN full scan triggered by empty updatedReports during reportAttributes hydration #83588 (Mar 3) changed LHN to avoid full scans — could affect which reports are re-evaluated but doesn't change the green dot conditions
• PR Defer startup imports #84390 (Mar 11) deferred UnreadIndicatorUpdater import until after splash screen — no impact since it's a no-op on Android anyway
• PR Fixed race conditions and redundant writes in OnyxDerived initialisation #82161 (Feb 25) deferred OnyxDerived writes — affects timing, not indicator logic

None of these changed the fundamental logic of when the green dot appears. The green dot has been gated on requiresAttention (not plain unread status) as far back as these changes go.

---

Next Steps for Contributor+ team: This needs a product decision — should the Inbox tab green dot indicate any unread messages, or only attention-requiring items? If the former, reply with @MelvinBot implement this to create a draft PR. If the latter, the test case TC-3233 should be updated.

[melvin-bot]

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

[melvin-bot]

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

[claw-56k]

Proposal

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

When User A is on a different tab (e.g., Reports) and User B sends a message in a common group chat, the green dot indicator on the Inbox tab does not appear for User A on Android.

What is the root cause of that problem?

The green dot on the Inbox tab is controlled by getChatTabBrickRoad in src/libs/WorkspacesSettingsUtils.ts, which only checks brickRoadStatus from reportAttributes. The brickRoadStatus is only set to INFO (green) when requiresAttention returns true, which only happens for: @mentions, outstanding tasks, expense approval requests, join requests, fraud alerts, and missing invoice bank accounts.

A plain new message (without @mention) in a group chat does NOT trigger requiresAttention, so brickRoadStatus remains undefined, and no green dot appears on the Inbox tab.

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

Modify getChatTabBrickRoadReportID in src/libs/WorkspacesSettingsUtils.ts to also check for unread reports (not just those with brickRoadStatus). The reportAttributes already computes isUnread for each report.

The fix would be:

function getChatTabBrickRoadReportID(orderedReportIDs: string[], reportAttributes: ReportAttributesDerivedValue["reports"] | undefined): string | undefined {
    if (!orderedReportIDs.length) {
        return undefined;
    }

    let reportIDWithGBR: string | undefined;

    for (const reportID of orderedReportIDs) {
        const brickRoad = getBrickRoadForPolicy(reportID, reportAttributes);
        if (brickRoad === CONST.BRICK_ROAD_INDICATOR_STATUS.INFO) {
            reportIDWithGBR = reportID;
        }
        if (brickRoad === CONST.BRICK_ROAD_INDICATOR_STATUS.ERROR) {
            return reportID;
        }
        // Check for unread messages if no brick road status yet
        if (!reportIDWithGBR && reportAttributes?.[reportID]?.isUnread) {
            reportIDWithGBR = reportID;
        }
    }

    return reportIDWithGBR;
}

This ensures the green dot appears for any unread message, not just attention-requiring items.

What alternative solutions did you explore? (Optional)

Alternative: Extend the brickRoadStatus computation in reportAttributes.ts to include a plain unread check. However, this would require modifying the derived value computation which is more complex and could have unintended side effects on other parts of the app that rely on brickRoadStatus having a specific meaning. The getChatTabBrickRoadReportID approach is more targeted and safer.

---

Contributor details
Your Expensify account email: claw@hourcom.fr
Upwork Profile Link: https://www.upwork.com/freelancers/~021234567890abcdef

[melvin-bot]

⚠️ Invalid email. Please make sure to create an Expensify account with this email first here.

[anobie]

Proposal

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

When two users share a group chat and User A navigates away from the Inbox tab (e.g. to Reports), User B sends a message in the group chat, but User A does not see a green dot on the Inbox tab icon indicating there are unread messages requiring attention.

What is the root cause of that problem?

The inbox tab green dot is determined by getChatTabBrickRoad(), which checks each sidebar report's brickRoadStatus. A report only gets brickRoadStatus = INFO (green) when requiresAttention is true, which is computed by getReasonAndReportActionThatRequiresAttention() in ReportUtils.ts.

That function checks for several GBR conditions, but for unread messages it only checks isUnreadWithMention() — which requires the message to contain an @mention. A regular group chat message (no @mention) makes the report unread (isUnread returns true), but isUnreadWithMention returns false. Since there is no plain isUnread check in the function, requiresAttention stays false, brickRoadStatus is never set to green, and the inbox tab green dot never appears for regular unread group messages.

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

1. Add a new IS_UNREAD constant to REQUIRES_ATTENTION_REASONS in src/CONST/index.ts.

2. In getReasonAndReportActionThatRequiresAttention() in src/libs/ReportUtils.ts, add a check for isUnread() immediately after the existing isUnreadWithMention() check. This way, messages with mentions still get the higher-priority IS_UNREAD_WITH_MENTION reason, while regular unread messages (including group chats) will now return IS_UNREAD — making requiresAttention true, setting brickRoadStatus to INFO, and causing the inbox tab green dot to appear.

What alternative solutions did you explore? (Optional)

An alternative would be to modify NavigationTabBar to compute the inbox green dot separately from the GBR system — for example, by reusing the UnreadIndicatorUpdater logic which already uses isUnread() for native app badge counts. However, this adds unnecessary complexity and diverges from the current architecture where the inbox tab dot and LHN dots are both derived from the same reportAttributes pipeline. The simpler approach of adding isUnread into the existing requiresAttention flow keeps things consistent.

[chengyixu]

Proposal

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

When a new message arrives in a group chat, the green unread indicator (dot) on the Inbox tab in the bottom navigation bar does not appear, even though the message is unread. The user has no visual cue to open the Inbox.

What is the root cause of that problem?

The green dot on the Inbox icon is driven by a selector (likely getUnreadReportsCount or an equivalent derived value from Onyx). For group chat reports, the unread count may not be incremented correctly when a new message arrives. Possible causes:

1. The group chat report is missing from the participants mapping that the selector iterates over (group reports may use a different type or chatType value that the selector filters out).
2. The lastReadTime / lastMessageTime comparison for group reports evaluates in a code path that does not update the Onyx unread flag.
3. The notification or reportAction for a group message triggers the correct Onyx write for the report but the selector watching for the dot re-render does not include REPORT_METADATA or the group-specific key.

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

1. Add a console.log / Reactotron trace to confirm whether the Onyx reports entry for the group chat has hasOutstandingChildTask or lastReadTime < lastMessageTime set correctly after the new message arrives.
2. Update the selector that drives the Inbox green dot to include group chat reports (ensure chatType === CONST.REPORT.CHAT_TYPE.GROUP is not inadvertently excluded).
3. If the unread flag in Onyx is correct but the UI does not re-render, verify that the tab bar icon component subscribes to the correct Onyx keys and re-renders when the unread count changes.
4. Add a test: send a message to a group chat, and assert the Inbox tab's unread indicator becomes visible.

What alternative solutions did you explore? Why did you reject them?

• Polling the unread count on a timer: rejected because it would miss instant updates and increase unnecessary re-renders.