[$250] Chat - The new message marker isn't displayed when user marks their own message as unread

[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.21-2
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/test-runs/62259272/folder/13177078/41237899/1521896345?sort=-identifier
Email or phone of affected tester (no customers): lekima20+627006@gmail.com
Issue reported by: Applause Internal Team
Bug source: Regression TC Execution
Device used: Win 11/Chrome
App Component: Chat Report View

Action Performed:

1. Open https://staging.new.expensify.com
2. Navigate to a thread conversation with several messages between user A and B
3. User A marks a message sent by user A as unread (note that new message marker isn't displayed)
4. User A marks a message sent by user B as unread
5. User A marks a message sent by user A as unread (note that new message marker is displayed)
6. User A navigates to another conversation
7. User A navigates back to the thread conversation

Expected Result:

The new message marker is displayed when mark a message as unread

Actual Result:

The new message marker isn't displayed when user A mark own message as unread at step 3 but it is displayed at step 5. The conversation is bolded in LHN as expected. Navigate to another conversation and turn back the thread, the new message marker isn't displayed

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7193691_1782668615821.Recording__2282.mp4

View all open jobs on GitHub

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

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022071307289351794797
• Upwork Job ID: 2071307289351794797
• Last Price Increase: 2026-06-28

[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/3ccfeb5462ade85c7338f1e1dcfc1a7e97e42442ed9216f8acdffc9db011bb68

[MelvinBot]

Proposal

What is the root cause of that problem?

The unread-marker scanner refuses to put the "New" marker above a message you authored yourself unless a marker was already showing on the previous render.

In shouldDisplayNewMarkerOnReportAction.ts:88-96, once a message is detected as self-authored:

• if prevUnreadMarkerReportActionID is set (a marker already existed) → it's allowed to move onto your own message,
• otherwise it returns false and the marker is never shown.

This guard was added for #91443 ("Self-authored posts should never be marked as unread") to stop your own just-sent messages from showing a "New" line. The problem is it also kills the legitimate case in this bug — explicitly marking your own message as unread — because on first open / re-entry there is no prior marker, so prevUnreadMarkerReportActionID is null and the function short-circuits to false.

This matches every symptom exactly:

• Step 3 (no marker): No marker is showing yet → prevUnreadMarkerReportActionID is null → self-authored branch returns false. No marker.
• Step 5 (marker shows): User B's message was already marked unread, so a marker already exists → prevUnreadMarkerReportActionID is set → marking your own earlier message just relocates the existing marker, which is allowed.
• Step 7 (gone after navigating back): Re-entering the report remounts the hook, so prevUnreadMarkerReportActionID resets to null (useUnreadMarker.ts:85, 123-125) → back to the Step 3 state. No marker.

The underlying lastReadTime is set correctly by markCommentAsUnread (LHN bolds correctly, as the report notes) — only the in-chat marker rendering is suppressed.

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

The function already computes shouldIgnoreUnreadForCurrentUserMessage, which is true only for a brand-new or previously-optimistic self message (i.e. one you just sent — the case #91443 wants suppressed) and false for an existing self message that became unread because you explicitly marked it.

So the prevUnreadMarkerReportActionID gate is unnecessary. For self-authored messages, simply return !shouldIgnoreUnreadForCurrentUserMessage in shouldDisplayNewMarkerOnReportAction.ts:88-96, independent of whether a marker already existed.

This keeps #91443's protection (a just-sent / optimistic self message stays unmarked, since shouldIgnoreUnreadForCurrentUserMessage is true for those) while restoring the marker when you deliberately mark your own already-saved message as unread.

Why this is safe for #91443

A self-authored message can only reach this branch with shouldIgnoreUnreadForCurrentUserMessage === false when it is not new and not previously-optimistic yet still appears unread (created > unreadMarkerTime). In normal operation your own sent messages immediately advance lastReadTime, and messages sent from another device are detected as new (isNewMessage). So the only realistic way to reach this state is an explicit "mark as unread" — exactly the case this issue wants to support.

Related issues

• [Due for payment 2026-07-03] [$250] Investigate: Self-authored posts should never be marked as unread #91443 — "Self-authored posts should never be marked as unread" — introduced the isFromCurrentUser suppression branch that causes this regression. Any fix here should be validated against that issue to avoid re-breaking it. It is due for payment 2026-07-03, so coordinate to avoid a conflicting change.

---

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

[MobileMage]

Proposal

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

When a user marks one of their own messages as unread, the green "New" message marker is not rendered above that message, even though the conversation is correctly bolded as unread in the LHN. Marking another user's message as unread does show the marker. The marker also disappears on navigating away and back to the conversation. We need the "New" marker to appear above a self-authored action that the user explicitly marked as unread.

What is the root cause of that problem?

The write path is correct. markCommentAsUnread in src/libs/actions/Report/index.ts sets lastReadTime to one millisecond before the marked action's created time and emits unreadAction_${reportID}, which pushes the new value into unreadMarkerTime via the listener in useUnreadMarker. So when the scan runs, isReportActionUnread(message, unreadMarkerTime) is correctly true for the marked self-authored action.

The bug is purely in the read/decision path — shouldDisplayNewMarkerOnReportAction in src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts. For a self-authored action it hard-blocks the marker unless a marker already exists:

App/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts

Lines 88 to 96 in 6ca714a

	if (isFromCurrentUser) {
	// When an existing marker is being relocated (e.g. after the original unread message is deleted),
	// allow the marker to land on a self-authored action.
	// Otherwise, never anchor the "New" marker above a self-authored action on first open/re-entry.
	if (prevUnreadMarkerReportActionID) {
	return !shouldIgnoreUnreadForCurrentUserMessage;
	}
	return false;
	}

When isFromCurrentUser is true and there is no prevUnreadMarkerReportActionID, the function returns false unconditionally. This guard was added in commit 59cd72c2f72 ("suppress New marker for self-authored actions when no marker exists") to stop the marker from anchoring above a newly arriving message the current user just sent. But the guard can't distinguish "a new self message just arrived" from "the user explicitly marked their own existing message as unread" — both reach this branch with prevUnreadMarkerReportActionID === null, so both get suppressed.

This explains the exact repro. Step 3 (mark own message): prevUnreadMarkerReportActionID is null → returns false, no marker. Step 4 (mark User B's message): isFromCurrentUser is false → returns !isNewMessage which is true, marker shows and prevUnreadMarkerReportActionID gets set. Step 5 (mark own message again): now prevUnreadMarkerReportActionID is set, so it takes the if (prevUnreadMarkerReportActionID) branch and returns true. Steps 6–7 (leave and return): prevUnreadMarkerReportActionID resets to null on re-entry, so the self-authored marked action hits the same !prevUnreadMarkerReportActionID block and the marker vanishes again. Notably, the only signal the guard actually needs — whether the message is genuinely new — is already computed two lines above as isNewMessage and folded into shouldIgnoreUnreadForCurrentUserMessage, but that value is ignored in the !prevUnreadMarkerReportActionID path.

I reproduced this end to end. Marking my own last message as unread when no marker exists yet moves lastReadTime back exactly one millisecond, so the action is genuinely unread and the conversation correctly shows as bold/unread in the LHN — yet no green "New message line indicator" renders in the chat. Marking the other party's message, or my own once a marker already exists, renders the indicator correctly. Because the unread state is written correctly and nothing throws, the marker is being suppressed purely by the isFromCurrentUser && !prevUnreadMarkerReportActionID branch returning false — confirming the defect is this decision check, not the unread data.

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

In shouldDisplayNewMarkerOnReportAction, the self-authored branch should gate on the same shouldIgnoreUnreadForCurrentUserMessage signal in both cases instead of returning a blanket false when no prior marker exists. shouldIgnoreUnreadForCurrentUserMessage (isNewMessage || isPreviouslyOptimistic) is exactly the "this self message just arrived / was just optimistically added" condition the original fix wanted to suppress. For a message the user explicitly marks as unread, the action already existed in prevSortedVisibleReportActionsObjects, so isNewMessage is false and isPreviouslyOptimistic is false — meaning the marker is allowed. Collapse the branch so both paths return the same thing:

if (isFromCurrentUser) {
    // Suppress only for newly arrived / previously-optimistic self-authored messages.
    // An existing self-authored action the user explicitly marked unread should show the marker.
    return !shouldIgnoreUnreadForCurrentUserMessage;
}

This is safe because the suppression still fires for the original scenario: a self message that just landed (or transitioned from optimistic to saved) has isNewMessage/isPreviouslyOptimistic true, so it still returns false and no marker is anchored above it. The existing "marker relocated after deletion" case (prevUnreadMarkerReportActionID set) is unchanged since it already returned !shouldIgnoreUnreadForCurrentUserMessage. The change only affects the first-open / re-entry case, which is precisely the broken scenario, and it makes self-authored and other-authored marked-unread actions behave consistently.

What alternative solutions did you explore? (Optional)

I considered persisting the unread marker action ID across navigation (e.g. deriving it from report.lastReadTime on re-entry) so the step 6–7 disappearance is fixed via prevUnreadMarkerReportActionID being non-null. I rejected it because it's a larger, riskier change that still wouldn't fix step 3 (the very first mark-unread with no prior marker), and the real defect is the over-broad self-author guard rather than missing marker persistence.

[lorretheboy]

Proposal

What is the root cause of that problem?

The "New" marker decision blocks self-authored messages from anchoring the marker unless an in-memory marker already exists. In shouldDisplayNewMarkerOnReportAction, when the action is from the current user it only returns true if prevUnreadMarkerReportActionID is already set; otherwise it hard-returns false:

App/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts

Lines 88 to 96 in 6ca714a

	if (isFromCurrentUser) {
	// When an existing marker is being relocated (e.g. after the original unread message is deleted),
	// allow the marker to land on a self-authored action.
	// Otherwise, never anchor the "New" marker above a self-authored action on first open/re-entry.
	if (prevUnreadMarkerReportActionID) {
	return !shouldIgnoreUnreadForCurrentUserMessage;
	}
	return false;
	}

prevUnreadMarkerReportActionID is component state that starts as null and is only populated once a marker has been rendered:

App/src/hooks/useUnreadMarker.ts

Line 85 in 6ca714a

const [prevUnreadMarkerReportActionID, setPrevUnreadMarkerReportActionID] = useState<string | null>(null);

App/src/hooks/useUnreadMarker.ts

Lines 123 to 125 in 6ca714a

	if (prevUnreadMarkerReportActionID !== unreadMarkerReportActionID) {
	setPrevUnreadMarkerReportActionID(unreadMarkerReportActionID);
	}

Causal chain: on a fresh open (step 3) or after navigating away and back (step 7), prevUnreadMarkerReportActionID is null → marking your own message unread hits the isFromCurrentUser branch → with no prior marker it returns false → no marker, and since the marker never renders, the state never gets set, so it stays false. At step 5 the marker already exists on user B's message, so prevUnreadMarkerReportActionID is truthy → the branch returns !shouldIgnoreUnreadForCurrentUserMessage (the message is neither new nor optimistic) → marker shows. That's exactly the reported difference between steps 3/7 and step 5.

The prevUnreadMarkerReportActionID gate is too strict: its real goal is to suppress the marker on a message the user just sent, but that case is already captured by shouldIgnoreUnreadForCurrentUserMessage (isNewMessage || isPreviouslyOptimistic):

App/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts

Lines 75 to 86 in 6ca714a

	// If no unread marker exists, don't set an unread marker for newly added messages from the current user.
	const isFromCurrentUser = currentUserAccountID === (isReportPreviewAction(message) ? message.childLastActorAccountID : message.actorAccountID);
	const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
	// The unread marker will show if the action's `created` time is later than `unreadMarkerTime`.
	// The `unreadMarkerTime` has already been updated to match the optimistic action created time,
	// but once the new action is saved on the backend, the actual created time will be later than the optimistic one.
	// Therefore, we also need to prevent the unread marker from appearing for previously optimistic actions.
	const isPreviouslyOptimistic =
	(isPendingAdd(prevSortedVisibleReportActionsObjects[message.reportActionID]) && !isPendingAdd(message)) ||
	(!!prevSortedVisibleReportActionsObjects[message.reportActionID]?.isOptimisticAction && !message.isOptimisticAction);
	const shouldIgnoreUnreadForCurrentUserMessage = isNewMessage || isPreviouslyOptimistic;

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

In the isFromCurrentUser branch, drop the prevUnreadMarkerReportActionID requirement and rely on shouldIgnoreUnreadForCurrentUserMessage alone:

App/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts

Lines 88 to 96 in 6ca714a

	if (isFromCurrentUser) {
	// When an existing marker is being relocated (e.g. after the original unread message is deleted),
	// allow the marker to land on a self-authored action.
	// Otherwise, never anchor the "New" marker above a self-authored action on first open/re-entry.
	if (prevUnreadMarkerReportActionID) {
	return !shouldIgnoreUnreadForCurrentUserMessage;
	}
	return false;
	}

So the branch becomes simply return !shouldIgnoreUnreadForCurrentUserMessage;.

This keeps the original intent — a freshly sent/optimistic self-authored message is isNewMessage/optimistic, so it still returns false and no marker appears above what you just sent. But a self-authored message you explicitly mark as unread is neither new nor optimistic (usePrevious seeds prevSortedVisibleReportActionsObjects with the current actions on mount, so isNewMessage is false on first open and re-entry), so it now correctly returns true and the marker shows in steps 3, 5, and 7 consistently.

What alternative solutions did you explore? (Optional)

Instead of removing the gate, persist the last marker position across mounts (e.g. derive it from the report's lastReadTime rather than transient component state) so prevUnreadMarkerReportActionID survives re-entry. This also fixes step 7 but is more invasive and doesn't fix step 3 (true first open), so the targeted change above is preferable.

[dilshodmackbook-sketch]

Proposal

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

When a user marks one of their own existing messages as unread, the "New" message marker is not rendered above that message, even though the conversation is correctly bolded as unread in the LHN. Marking another user's message as unread does show the marker, and on the user's own message it shows only on a later attempt (step 5) and disappears again after navigating away and back.

What is the root cause of that problem?

The write path is correct. markCommentAsUnread sets lastReadTime to one millisecond before the marked action's created and emits unreadAction_${reportID}, which useUnreadMarker pushes into unreadMarkerTime, so isReportActionUnread(message, unreadMarkerTime) is correctly true for the marked action regardless of who authored it (hence the LHN bold). The bug is purely in the display decision.

In shouldDisplayNewMarkerOnReportAction, the current-user branch suppresses the marker based on isNewMessage:

App/src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts

Lines 72 to 89 in 62df01f

	// If no unread marker exists, don't set an unread marker for newly added messages from the current user.
	const isFromCurrentUser = currentUserAccountID === (isReportPreviewAction(message) ? message.childLastActorAccountID : message.actorAccountID);
	const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
	// The unread marker will show if the action's `created` time is later than `unreadMarkerTime`.
	// The `unreadMarkerTime` has already been updated to match the optimistic action created time,
	// but once the new action is saved on the backend, the actual created time will be later than the optimistic one.
	// Therefore, we also need to prevent the unread marker from appearing for previously optimistic actions.
	const isPreviouslyOptimistic =
	(isPendingAdd(prevSortedVisibleReportActionsObjects[message.reportActionID]) && !isPendingAdd(message)) ||
	(!!prevSortedVisibleReportActionsObjects[message.reportActionID]?.isOptimisticAction && !message.isOptimisticAction);
	const shouldIgnoreUnreadForCurrentUserMessage = isNewMessage || isPreviouslyOptimistic;
	if (isFromCurrentUser) {
	return !shouldIgnoreUnreadForCurrentUserMessage;
	}
	return !isNewMessage || isScrolledOverThreshold || !hasWindowFocus;

const isNewMessage = !prevSortedVisibleReportActionsObjects[message.reportActionID];
...
const shouldIgnoreUnreadForCurrentUserMessage = isNewMessage || isPreviouslyOptimistic;

if (isFromCurrentUser) {
    return !shouldIgnoreUnreadForCurrentUserMessage;
}

That branch exists to suppress the marker for a message the user just sent. But isNewMessage is derived purely from "not present in the previous render's visible actions," and prevSortedVisibleReportActionsObjects does not yet contain the existing actions until a render after they have loaded (i.e. on the first render after entering or re-entering the report). On that render every existing message — including the current user's own — is classified as "new," so shouldIgnoreUnreadForCurrentUserMessage is true and the marker is suppressed.

This matches the repro exactly. Step 3: the thread was just opened, prev does not yet contain the action → own message marker is hidden. Step 5: by then several renders have happened so prev contains the action → isNewMessage is false → the marker shows. Steps 6-7 (navigate away and back): prev is empty again on re-entry → marker hidden once more. Other users' messages are unaffected because their branch (return !isNewMessage || isScrolledOverThreshold || !hasWindowFocus) has fallbacks that the current-user branch lacks.

The suppression is also persistent rather than a single dropped frame: when the current-user branch returns false the scan finds no marker, which lets the auto-advance in useUnreadMarker push unreadMarkerTime forward to the newest action, so the marked action is no longer "after" the marker time until the next manual mark.

App/src/hooks/useUnreadMarker.ts

Lines 121 to 127 in 62df01f

	// When the user reads a new message as it is received, push unreadMarkerTime down to the
	// latest action's timestamp so new incoming actions display over those new messages instead of
	// sticking to the initial lastReadTime.
	const mostRecentReportActionCreated = sortedVisibleReportActions.at(0)?.created ?? '';
	if (!isAnonymousUser && !unreadMarkerReportActionID && mostRecentReportActionCreated > unreadMarkerTime) {
	setUnreadMarkerTime(mostRecentReportActionCreated);
	}

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

Only treat a message as newly added when there actually was a previous set of visible actions that did not include it, so the empty-prev render no longer misclassifies existing messages:

// On the first render after (re)entering the report, prevSortedVisibleReportActionsObjects doesn't yet
// contain the existing actions, which would misclassify every message (including the current user's own)
// as newly added and hide the unread marker. Treat a message as new only when there was a prior set of
// visible actions that didn't contain it.
const hasPrevVisibleActions = Object.keys(prevSortedVisibleReportActionsObjects).length > 0;
const isNewMessage = hasPrevVisibleActions && !prevSortedVisibleReportActionsObjects[message.reportActionID];

With this, marking your own message as unread shows the marker on the first render (step 3) and after navigating back (step 7), while a genuinely just-sent message — where prev is already populated and lacks the new action — is still correctly skipped. Because the scan now finds the marker, the auto-advance in useUnreadMarker no longer clobbers unreadMarkerTime, so the fix holds across re-entry.

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

A unit test for shouldDisplayNewMarkerOnReportAction:

• Current user's own existing action, unreadMarkerTime set just before its created, and an empty prevSortedVisibleReportActionsObjects (first-populate / re-entry render) → expect true.
• A genuinely just-sent own action that is absent from a non-empty prevSortedVisibleReportActionsObjects → expect false.
• An own action transitioning from optimistic to saved (isPreviouslyOptimistic) → expect false.

End-to-end matching the repro: in a thread, mark an own message as unread → assert the marker renders above it; navigate away and back → assert it is still rendered.

What alternative solutions did you explore? (Optional)

Always show the marker for the current user's messages whenever the action is unread. I rejected this because it reintroduces the marker flashing above a message the user just sent; keying off whether a prior set of visible actions existed preserves that suppression while fixing the mark-as-unread case. I also considered persisting the marker's anchor across navigation so re-entry keeps it, but that is a larger, riskier change and does not fix the very first mark-unread (step 3) where no prior marker exists.

[melvin-bot]

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

[melvin-bot]

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