Show New message marker when a user marks their own message as unread by MelvinBot · Pull Request #95217 · Expensify/App

MelvinBot · 2026-07-02T15:53:25Z

Explanation of Change

When a user marks their own message as unread, the green "New" message marker was not shown above that message, even though the conversation was correctly bolded as unread in the LHN. Marking another user's message worked fine, and the marker only appeared inconsistently (e.g. after a marker already existed) and disappeared again after navigating away and back.

The write path is correct — markCommentAsUnread sets lastReadTime to just before the marked action, so the action is genuinely unread regardless of author. The bug was purely in the display decision in shouldDisplayNewMarkerOnReportAction. For a self-authored action it hard-blocked the marker unless a marker already existed:

if (isFromCurrentUser) {
    if (prevUnreadMarkerReportActionID) {
        return !shouldIgnoreUnreadForCurrentUserMessage;
    }
    return false;
}

prevUnreadMarkerReportActionID starts as null on first open and resets to null on re-entry, so the return false suppressed the marker in exactly the reported scenarios. This guard was introduced by #91940 (issue #91443) to stop the marker from anchoring above a message the user just sent, but that case is already fully captured by shouldIgnoreUnreadForCurrentUserMessage (isNewMessage || isPreviouslyOptimistic).

This change collapses the branch to return !shouldIgnoreUnreadForCurrentUserMessage, so:

A just-sent / optimistic self message is still suppressed (shouldIgnoreUnreadForCurrentUserMessage is true), preserving the fix from [Due for payment 2026-07-03] [$250] Investigate: Self-authored posts should never be marked as unread #91443.
An existing self message the user explicitly marked as unread (neither new nor optimistic) now correctly anchors the marker on first open, after marking, and after navigating away and back.

The now-unused prevUnreadMarkerReportActionID param is dropped from this function's destructuring. A unit test for the explicit self-mark-unread case was updated to assert the marker now shows.

Fixed Issues

$ #94794
PROPOSAL: #94794 (comment)

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"

Open a thread/chat with several messages between user A and user B.
As user A, mark one of your own messages as unread.
Verify the green "New" message marker appears above that message (and the chat is bolded as unread in the LHN).
Navigate to another conversation, then navigate back to this thread.
Verify the "New" marker is still displayed above the message.
Send a new message as user A and verify no "New" marker appears above the message you just sent.

Verify that no errors appear in the JS console

Offline tests

Same as Tests.

QA Steps

// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".

Open a thread/chat with several messages between user A and user B.
As user A, mark one of your own messages as unread.
Verify the green "New" message marker appears above that message.
Navigate away and back; verify the marker is still displayed.
Send a new message and verify no "New" marker appears above your just-sent message.

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videosundefined

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot · 2026-07-02T15:59:54Z

🤖 I looked into the failing checks. There's no code issue to fix — the only failing check is PR Author Checklist / checklist, which fails because the author checklist isn't filled out:

You completed 0 out of 41 checklist items with 41 unfinished items
PR Author Checklist is not completely filled out. Please check every box to verify you've thought about the item.

This is a human-completed checklist, so I can't/shouldn't auto-tick it — Ollyws, please check the boxes in the PR description to clear it.

Every automated code check is green: typecheck, all 8 test jobs, ESLint, Prettier, Bun tests, Storybook, knip, unused styles, React Compiler, and the completed builds all pass. The only checks still running are the long-lived standalone builds and perf tests, which don't indicate any problem with the diff.

No commit was pushed since nothing in the code needs changing.

MelvinBot · 2026-07-02T16:06:56Z

🤖 The newly-failing check — build (New Expensify Dev, DebugDevelopment, false) — is an unrelated flaky iOS build failure, not something this PR caused. I did not push anything.

Analysis: This PR only touches two TypeScript files — src/pages/inbox/report/shouldDisplayNewMarkerOnReportAction.ts and tests/unit/ReportActionsUtilsTest.ts. The failing job died in the native Xcode/Swift compile step with a generic infra error and no compiler error attributable to the diff:

● Remote cache failure error: NoSuchKey: The specified key does not exist.
■ Failed: Building the app
■ RockError: Failed to build the project
  [cause]: "xcodebuild -workspace NewExpensify.xcworkspace ... -scheme 'New Expensify Dev' ..."

A JS/TS-only change cannot break native iOS Swift compilation — and indeed every other build passed, including the Android build build (Expensify Dev, Debug, true). That asymmetry (iOS fails, Android + all JS bundling succeed) is the signature of a flaky iOS builder / remote-cache miss, not a code problem.

Recommendation: Re-run the failing iOS build job — it should pass on retry.

The other failing check, PR Author Checklist / checklist, is just the unchecked author checklist (0/41 items) — Ollyws, please tick the boxes in the PR description to clear it. Every automated code check (typecheck, all 8 test jobs, ESLint, Prettier, Bun tests, Storybook, knip, unused styles, React Compiler) is green.

Ollyws · 2026-07-15T16:25:57Z

@MelvinBot mark this as ready to review.

melvin-bot · 2026-07-15T16:28:01Z

@Ollyws Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

MelvinBot · 2026-07-15T16:28:07Z

🤖 Done — this PR is now marked Ready for review.

Two heads-ups before reviewers dig in:

The Tests and QA Steps sections still contain // TODO placeholders for the human co-author to fill in (the steps you actually ran + checking off the console-error box). Reviewers will expect these completed.
I could not verify the change in a browser in this run (no dev web backend available), so the "New" marker behavior described in the PR is based on the code change only, not a live check.

JmillsExpensify

LGTM

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c52f485375

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-07-15T16:31:54Z

    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;
+        // Only suppress the "New" marker for a self-authored message that was just sent (newly added or still
+        // transitioning from an optimistic action). An existing self-authored action that the user explicitly
+        // marked as unread should anchor the marker even when no marker exists yet (e.g. on first open/re-entry).
+        return !shouldIgnoreUnreadForCurrentUserMessage;


Preserve the self-message suppression for cold opens

This now treats any persisted self-authored action as a valid unread-marker anchor, not only actions explicitly marked unread. On a cold open/re-entry after the user's just-sent message has been confirmed with a server created time later than the optimistic lastReadTime, usePrevious initializes the previous-actions map with the current actions, so isNewMessage and isPreviouslyOptimistic are both false and this return shows the green marker above the user's own message, reintroducing the self-message marker case this guard previously prevented.

Useful? React with 👍 / 👎.

MelvinBot · 2026-07-15T16:33:31Z

The failing build is a flaky iOS infra failure — not caused by this PR

No code fix is needed. This PR only changes two pure JS/TS files (shouldDisplayNewMarkerOnReportAction.ts and a unit test), and the failing check is the iOS native xcodebuild step, which doesn't compile that JS (it's served by Metro at runtime). The build just needs a re-run.

I attempted to re-run the failed job automatically but couldn't in this environment. Please click Re-run failed jobs on the failed build run, or push any trivial change to re-trigger it.

Evidence

Only iOS failed. build (New Expensify Dev, DebugDevelopment, false) failed, but all three other native builds (build (developmentDebug, false), build (Debug, true), build (Expensify Dev, Debug, true)) passed on the same commit, as did typecheck, ESLint, Prettier, Bun tests, all 8 test jobs, and Storybook tests.
No compile error in the log. The build ends with a generic RockError: Failed to build the project / Failed: Building the app — there is no error: diagnostic anywhere, and it got all the way through compiling Pods.
Infrastructure errors are present: Blacksmith cache setup failed, using standard checkout: Error: gRPC connection test failed: [unavailable] connect ETIMEDOUT and Remote cache failure error: NoSuchKey: The specified key does not exist.
Mechanism: the change is display logic + a Jest test. The iOS native build compiles Objective-C/Swift/C++; it does not bundle or type-check the app's JS/TS. A change to these files cannot break xcodebuild.

The two checklist failures (PR Author Checklist / PR Reviewer Checklist) are expected — they stay red until the human co-author fills out the checklist boxes and testing sections, so no action from me there.

Note: I could not verify anything in a browser in this run, but that isn't needed here — the conclusion is based on the CI logs and the PR diff.

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot · 2026-07-15T16:36:16Z

I pushed an empty commit (669f3f53) to re-trigger CI, since the failing build (New Expensify Dev, DebugDevelopment, false) check was a flaky iOS infrastructure failure, not a code defect — so there was nothing to fix in the source.

As detailed in my previous comment: this PR only changes JS/TS (a display-logic function + a unit test), the iOS native xcodebuild step doesn't compile that JS, all three other native builds passed on the same commit, and the failed log contained no compile error — only infra errors (Blacksmith cache setup failed: gRPC ... ETIMEDOUT, Remote cache failure error: NoSuchKey).

The re-run is in progress now. The two checklist failures are the standard PR Author/Reviewer Checklist checks and stay red until the human co-author fills out the checklist and testing sections.

I could not verify anything in a browser this run, but that isn't needed here — the conclusion rests on the CI logs and the PR diff.

melvin-bot · 2026-07-15T16:36:26Z

@lakchote Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

MelvinBot · 2026-07-15T16:39:51Z

The flaky iOS build is resolved — only the checklist remains

The previously-failing build (New Expensify Dev, DebugDevelopment, false) was a flaky iOS infra failure (Blacksmith cache/gRPC timeout, no compile error, JS-only diff). It has been re-triggered via commit 669f3f53, and on the current HEAD the build failure is gone — every completed check passes and the remaining test/perf/typecheck jobs are green or still running.

The only remaining red check is PR Author Checklist, which stays failing until the human co-author fills out the checklist boxes and the Tests / QA Steps sections in the PR description (they're currently // TODO placeholders). That's not something I can or should fix — it needs the author to complete it.

So there's no code fix required. Once the checklist is completed and the in-progress test jobs finish, the PR should be clean.

Note: I could not verify in a browser in this run, but that isn't needed here — this is based on the CI status and the PR diff.

MelvinBot · 2026-07-15T16:44:24Z

The flaky iOS build is resolved — nothing left to fix in code

The re-trigger commit (669f3f53) cleared the previously-failing iOS build. On the current head:

✅ iOS build — no longer failing (it wasn't caused by this PR; it was a flaky infra failure).
✅ typecheck — passing (this is the check directly relevant to the TS change in this PR).
✅ All functional checks passing: test (jobs 1–8), Bun tests, ESLint, Oxfmt, Storybook tests, Check for unused styles, React Compiler Compliance, spellcheck, validate, dryRun, etc.
⏳ baseline-perf-tests / branch-perf-tests — still running at the time of writing. They passed on the prior commit (which has identical app JS, since the re-trigger commit added no code), so they're expected to pass again.
❌ checklist — still red, but this is expected. The PR Author Checklist / PR Reviewer Checklist checks stay red until the human co-author fills out the checklist boxes and the Tests / QA Steps sections. No action from me there.

So there's no code fix required — the only real failure was the flaky iOS build, which is now cleared. Just complete the checklist/testing sections when the PR is ready for review.

Note: I could not verify anything in a browser in this run, but that isn't needed here — this is based on the CI check results and the PR diff.

lakchote · 2026-07-16T14:11:30Z

@Ollyws can you add a video test? The test steps are still the placeholders.

Ollyws · 2026-07-20T09:53:18Z

Reviewer Checklist

I have verified the author checklist is complete (all boxes are checked off).
I verified the correct issue is linked in the ### Fixed Issues section above
I verified testing steps are clear and they cover the changes made in this PR
- I verified the steps for local testing are in the Tests section
- I verified the steps for Staging and/or Production testing are in the QA steps section
- I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
- I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
I checked that screenshots or videos are included for tests on all platforms
I included screenshots or videos for tests on all platforms
I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
I verified tests pass on all platforms & I tested again on:
- Android: HybridApp
- Android: mWeb Chrome
- iOS: HybridApp
- iOS: mWeb Safari
- MacOS: Chrome / Safari
If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
I verified proper code patterns were followed (see Reviewing the code)
- I verified that comments were added to code that is not self explanatory
- I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
- I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
I verified that this PR follows the guidelines as stated in the Review Guidelines
I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
If a new component is created I verified that:
- A similar component doesn't exist in the codebase
- All props are defined accurately
- The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
- The only data being stored in the state is data necessary for rendering and nothing else
- The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
If a new CSS style is added I verified that:
- A similar style doesn't already exist
- The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
- I verified that all the inputs inside a form are aligned with each other.
- I added Design label and/or tagged @Expensify/design so the design team can review the changes.
For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

01_Android_Native.mp4

Android: mWeb Chrome

02_Android_Chrome.mp4

iOS: HybridApp

03_iOS_Native.mp4

iOS: mWeb Safari

05_MacOS_Chrome.mp4

MacOS: Chrome / Safari

MacOS_Safari.mp4

Ollyws · 2026-07-20T11:23:12Z

@MelvinBot if you mark an optimistic message as unread while offline, the unread marker will disappear when you come back online.

MelvinBot · 2026-09-14T11:41:36Z

Fixed — it was branch staleness, not a defect in this PR. Merged main into the branch (c4a3e80), no source changes needed. All 8 test jobs and typecheck now pass.

Why it failed: CI tests the PR merged with main, and this branch was 4 days behind. The PR changes zero lines of src/libs/SearchUIUtils.ts or its test — so the failure came entirely from main's side of the merge.

Evidence and verification

It was never this PR's code. git diff --stat <merge-base> HEAD for tests/unit/Search/SearchUIUtilsTest.ts and src/libs/SearchUIUtils.ts is empty. The CI failure pointed at line 12477, but the branch's own copy had that assertion at line 12097 — proof CI was running main's much newer version of the file.

The typecheck failure had the same root cause: Property 'rules' is missing in type ... but required in type 'GetSectionsParams' in the same test file. Current main passes rules at every one of those call sites, so main was transiently broken when this run executed and has since been fixed.

Verified after merging current main:

Check	Result
`tests/unit/Search/SearchUIUtilsTest.ts`	576 passed
Full Jest suite (6 local shards)	1,429 suites / ~25k tests passed
`tsc --build` on all 5 referenced projects	clean
`./scripts/lintChanged.sh`	clean
PR-specific suites (`ReportTest`, `useUnreadMarkerTest`, `ReportActionsUtilsTest`, `ReportFetchHandlerTest`)	741 passed

The only remaining red check is Check independent approval, which is a human review gate.

One local-only note: tests/unit/removeInvisibleCharacters.ts failed on my first run from a stale Jest transform cache predating the regexpu-core emoji patch. It passes after jest --clearCache, and passed in CI.

view run · no recording available

Ollyws · 2026-09-14T12:09:58Z

All updated.

luacmartins

Thanks! Can we simplify the comments in this PR please? They're quite long

Ollyws · 2026-09-15T12:29:38Z

@MelvinBot reduce the comments in this PR to be more concise.

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot · 2026-09-15T12:39:27Z

Done — pushed 3e967d6. Comments only, no logic changes: 58 insertions, 104 deletions across 8 files.

The biggest cuts were the block comments in Report/index.ts (the 8-line optimisticData rationale → 3 lines, the 5-line reportsNavigatedAwayFrom header → 3), the 9-line manual-anchor comment in shouldDisplayNewMarkerOnReportAction.ts → 4, and the per-test preambles in ReportActionsUtilsTest.ts. In each case I kept the "why" and dropped the restatement of what the code already says.

Two judgement calls worth flagging:

I deleted the // Track whatever the marker last landed on line in useUnreadMarker.ts — it only restated the if below it.
The comment inside readNewestAction's Onyx value claimed "The explicit 'Mark as read' clears it here", but nothing on that path clears manuallyMarkedUnreadReportActionID — shouldResetUnreadMarker only emits a DeviceEventEmitter event. I rewrote it to describe what the code actually does and moved it above the block. If an explicit "Mark as read" is supposed to clear the marker, that's a real gap in the implementation, not just the comment — worth a look.

Verification

Confirmed comment-only by filtering the diff for non-comment lines — empty result.

Tests (all pass, 735 total):

tests/unit/ReportActionsUtilsTest.ts — 422 passed
tests/actions/ReportTest.ts — 303 passed
tests/unit/useUnreadMarkerTest.ts — 10 passed

ESLint passes on the changed files. One pre-existing no-restricted-syntax error surfaced on src/types/onyx/Report.ts:7 (a namespace import this PR never touches) — it's grandfathered by the lint seatbelt, so lint-changed is unaffected.

Not run: npm run lint-changed and npm run prettier couldn't execute in this environment. The App checkout here is shallow, so the lint script's git merge-base origin/main HEAD fails; I linted the changed files directly instead. Prettier resolved a config outside the App checkout and failed on a missing plugin. Both run normally in CI.

view run · no recording available

Ollyws · 2026-09-15T13:11:16Z

@MelvinBot resolve conflicts

…readMarker Co-authored-by: Olly <Ollyws@users.noreply.github.com> # Conflicts: # src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

MelvinBot · 2026-09-15T13:22:45Z

Conflicts resolved — merged main into the branch as b62d637 and pushed. The PR is now MERGEABLE.

There was one conflict, in src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx. main refactored that call site from calling getUnreadMarkerReportAction directly to using the useUnreadMarker hook, and added a useMarkAsRead call after it.

I took main's side, dropping this PR's added line. That's not a loss of behavior: the merged useUnreadMarker now reads manuallyMarkedUnreadReportActionID from Onyx itself and passes it into getUnreadMarkerReportAction, so the money-request report view still gets the manual-mark anchor through the hook. Passing it explicitly would have been redundant, and the prop no longer exists on the hook's API. Visibility.hasFocus() moved inside the hook the same way.

Everything else merged cleanly, and all of this PR's logic survived intact.

⚠️ Heads up, unrelated to this PR: main is currently failing typecheck. InboxTabSelector.tsx declares shouldUseNarrowLayout twice (lines 40 and 47), giving TS2451: Cannot redeclare block-scoped variable. I verified it's identical on origin/main, so it isn't from this merge and I left it alone per policy — but it will fail this PR's checks until someone fixes it on main.

Verification

Merge shape: normal two-parent merge commit (3e967d6 + 2abbf86). No rebase, squash, amend, or force-push — the original commits are untouched.

Tests — 772 passed, 0 failed:

tests/unit/ReportActionsUtilsTest.ts — 431 passed
tests/actions/ReportTest.ts — 303 passed
tests/unit/useUnreadMarkerTest.ts — 10 passed
tests/unit/useMarkAsReadTest.ts + useMoneyRequestReportVisibleActionsTest.tsx — 28 passed (run because my resolution wires up main's new useMarkAsRead)

Typecheck: the only errors are the two pre-existing InboxTabSelector.tsx lines above. My resolution introduced no type errors.

Lint: the resolved file reports one react-hooks/set-state-in-effect error at line 446 (setEnableScrollToEnd). That's main's scroll code, byte-identical on origin/main at the same line, and grandfathered by the lint seatbelt — not from this merge.

I also confirmed no stale references were left behind: Visibility and getUnreadMarkerReportAction are no longer imported or referenced in the resolved file.

view run · no recording available

Ollyws · 2026-09-15T13:48:50Z

@MelvinBot merge main

…readMarker Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot · 2026-09-15T13:59:31Z

Merged main into the branch and pushed a1989f7. No conflicts — the branch was 6 commits behind.

One thing to be aware of: main's #100947 deleted src/hooks/useSortedActions.ts and replaced it with useSortedReportActionsData.ts. A clean textual merge wouldn't catch a stale import of a deleted file, so I checked explicitly — nothing in src/ or tests/ references useSortedActions, and npm run typecheck passes.

Verification

Merge was clean (ort strategy, 12 files from main, no conflicts).

npm run typecheck — passed across all tsconfigs
tests/unit/ReportActionsUtilsTest.ts — 429 passed
tests/actions/ReportTest.ts — 303 passed
tests/unit/useUnreadMarkerTest.ts — 12 passed

744 tests total across the suites this PR touches.

view run · no recording available

Ollyws · 2026-09-15T14:59:53Z

@luacmartins updated.

luacmartins

LGTM. @lakchote all yours

github-actions · 2026-09-16T20:15:42Z

🚧 luacmartins has triggered a test Expensify/App build. You can view the workflow run here.

OSBotify · 2026-09-16T20:19:11Z

✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

github-actions · 2026-09-16T20:19:34Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #95217.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-9036d82-dc1bc78-e7a7e0b993d6e6990a026a17188ae28825ff7eec/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-9036d82-dc1bc78-d60230030923073f6412fd51a11ab7c47372043f/index.html

Web 🕸️
https://95217.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

OSBotify · 2026-09-17T22:20:01Z

🚀 Deployed to staging by https://github.com/luacmartins in version: 9.4.82-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	cancelled 🔪
🍎 iOS 🍎	cancelled 🔪

MelvinBot · 2026-09-17T22:45:14Z

Help site review: one change required (a gap, not a correction)

No existing article in docs/articles is made inaccurate by this PR. I grepped every article for the unread flow — the only hits are the Unread Inbox tab in Navigating New Expensify, #focus in Prioritize and Pin Chats, and the is:unread search operator. None of them describe the "New" marker or the mark-as-unread action, so nothing needed correcting.

What I did find is a gap: the Mark as unread / Mark as read actions are not documented anywhere on the help site, even though Chat Features and Moderation Tools covers every other message action (edit, delete, reply in thread, flag). Since this PR is what makes the marker behave correctly for a member's own message, it's the right moment to document the workflow.

Draft PR: Docs updates for E/A#95217 document marking a chat or message as unread — one new article, docs/articles/new-expensify/chat/Mark-a-Chat-or-Message-as-Unread.md. HelpDot applied, assigned to Ollyws.

What the article covers and how labels were verified

Covered:

Marking an individual message as unread — web (hover, then the three dots (⋮)) and mobile (long-press).
Marking a whole chat as unread or read from the Inbox, including that Mark as read exists for a whole chat only, not for an individual message (ContextMenuActions.tsx:623 gates it on type === CONTEXT_MENU_TYPES.REPORT && isUnreadChat).
What happens afterwards: the marked message and everything after it counts as unread, the chat is bold in the Inbox and counted in the Unread tab, and a green New line appears above the marked message.
That marking your own message works the same as marking someone else's — the behavior this PR fixed.
That read state is personal and notifies nobody.

Labels came from source rather than paraphrase: en.ts:874-875 gives Mark as unread and Mark as read, and UnreadActionIndicator.tsx:30 renders common.new = New. The Unread tab name matches the existing Navigating New Expensify article.

Written against HELPSITE_NAMING_CONVENTIONS.md, HELP_AUTHORING_GUIDELINES.md, and TEMPLATE.md: one workflow, single # title plus # FAQ, task-based ## headings only, YAML metadata with internalScope, bolded UI labels, separate Web/Mobile steps, the mandated three dots (⋮) phrasing, one screenshot placeholder with a stated purpose, and one relative cross-link. ./.github/scripts/createDocsRoutes.sh passes, so no _routes.yml change is needed.

One caveat to check while you review. I could not verify the flow in the live UI — the per-message hover toolbar never mounted in the headless web session, so app-web-tester could never open the message menu (it did confirm the marker renders as New). Every label above is therefore sourced from code, not a screenshot. The one claim that goes beyond a label is the FAQ answer "Why is the green New line gone when you return to a chat?", which says leaving and returning, or reloading, clears the line. That follows the merged code — openReport clears manuallyMarkedUnreadReportActionID on a return trip or a cold start — but it is the item most worth your eyes.

@Ollyws, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

OSBotify · 2026-09-18T18:06:27Z

🚀 Deployed to staging by https://github.com/luacmartins in version: 9.4.86-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

MelvinBot · 2026-09-18T18:32:21Z

🤖 Yes — help site changes are required. Draft PR: Docs updates for E/A#95217 document marking a chat or message as unread (Expensify/App#101613)

Mark as unread, Mark as read, and the green New marker have no coverage anywhere under docs/articles — grep -ril "mark as unread" docs/articles/ returns nothing. So there was no stale article to correct; the docs PR adds the missing one.

This PR changed user-visible behavior worth documenting: marking your own message as unread now anchors the New marker above it, the marker stays put while you remain in the chat, and a just-sent message still never gets the marker.

What the docs PR does

Adds docs/articles/new-expensify/chat/Mark-a-Chat-or-Message-as-Unread.md — how to mark a message as unread, how to mark a chat as unread or read, what the New marker shows, and how long it stays.
Registers it under the Chat hub in docs/_data/_routes.yml.

A new article rather than a new section in Chat-Features-and-Moderation-Tools.md, because HELP_AUTHORING_GUIDELINES.md Section 1 requires one workflow per article and that file already carries five.

Label verification and the one thing I could not check

I could not verify against the running app. A web tester tried the flow but could not open the message context menu in the headless session — right-click returned UNSUPPORTED_OPERATION, long-press is unsupported on web, and hover was accepted by the CLI but never triggered the app's hover state. Every label below is therefore read from source, not observed on screen.

Article text	Source
Mark as unread	`src/languages/en.ts:874`
Mark as read	`src/languages/en.ts:875`
New	`src/languages/en.ts:84`, rendered by `src/components/UnreadActionIndicator.tsx:30`

Behavior claims come from the same place: Mark as unread shows on a message and on a read chat (ContextMenuActions.tsx:544-546); Mark as read shows only on an unread chat, never on a single message (ContextMenuActions.tsx:624); opening a chat marks it read (useMarkAsRead.ts:178).

Worth your attention: this PR's own test steps say the marker is still shown after navigating away and back, but the merged code clears manuallyMarkedUnreadReportActionID on the return trip and on refresh, and opening the chat marks it read. I wrote the article to match the merged code. If the marker really does survive a return trip, the "How long the New marker stays on a message" section needs to change.

./.github/scripts/createDocsRoutes.sh (the check validateDocsRoutes.yml runs) passes. I left ### Fixed Issues blank on the docs PR — it's a docs-only follow-up, and $-linking the already-closed issue would have the automation treat this PR as fixing it.

@Ollyws, please review the linked help site PR and confirm it reflects the current behavior. Then mark the linked help site PR Ready for review

OSBotify · 2026-09-18T19:22:54Z

🚀 Deployed to staging by https://github.com/luacmartins in version: 9.4.89-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	success ✅

OSBotify · 2026-09-18T19:58:08Z

🚀 Deployed to production by https://github.com/luacmartins in version: 9.4.89-0 🚀

platform	result
🕸 web 🕸	success ✅
🤖 android 🤖	success ✅
🍎 iOS 🍎	failure ❌

Bundle Size Analysis (Sentry):

Android

MelvinBot · 2026-09-18T20:08:30Z

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

Show New marker when user marks their own message as unread

c52f485

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot assigned Ollyws Jul 2, 2026

MelvinBot requested a review from a team July 2, 2026 15:53

MelvinBot mentioned this pull request Jul 2, 2026

[Due for payment 2026-09-25] [$250] Chat - The new message marker isn't displayed when user marks their own message as unread #94794

Open

7 tasks

MelvinBot marked this pull request as ready for review July 15, 2026 16:27

MelvinBot requested a review from a team as a code owner July 15, 2026 16:27

melvin-bot Bot requested review from JmillsExpensify and Ollyws and removed request for a team July 15, 2026 16:27

melvin-bot Bot removed the request for review from a team July 15, 2026 16:28

JmillsExpensify removed their request for review July 15, 2026 16:28

JmillsExpensify previously approved these changes Jul 15, 2026

View reviewed changes

chatgpt-codex-connector Bot reviewed Jul 15, 2026

View reviewed changes

Re-trigger CI (flaky iOS build)

669f3f5

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

MelvinBot requested a review from a team as a code owner July 15, 2026 16:35

melvin-bot Bot requested review from lakchote and removed request for a team July 15, 2026 16:36

tgolen removed their request for review September 14, 2026 16:39

luacmartins reviewed Sep 14, 2026

View reviewed changes

Make the unread-marker comments more concise

3e967d6

Co-authored-by: Olly <Ollyws@users.noreply.github.com>

Merge remote-tracking branch 'origin/main' into claude-selfAuthoredUn…

b62d637

…readMarker Co-authored-by: Olly <Ollyws@users.noreply.github.com> # Conflicts: # src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Merge remote-tracking branch 'origin/main' into claude-selfAuthoredUn…

a1989f7

…readMarker Co-authored-by: Olly <Ollyws@users.noreply.github.com>

luacmartins approved these changes Sep 15, 2026

View reviewed changes

luacmartins merged commit 9036d82 into main Sep 16, 2026
42 of 43 checks passed

luacmartins deleted the claude-selfAuthoredUnreadMarker branch September 16, 2026 20:15

OSBotify mentioned this pull request Sep 17, 2026

Deploy Checklist: New Expensify 2026-09-17 #101475

Closed

82 tasks

MelvinBot mentioned this pull request Sep 17, 2026

[No QA] Docs updates for E/A#95217 document marking a chat or message as unread #101494

Draft

40 tasks

MelvinBot mentioned this pull request Sep 18, 2026

[No QA] Docs updates for E/A#95217 document marking a chat or message as unread #101613

Draft

40 tasks

Conversation

MelvinBot commented Jul 2, 2026 • edited by JmillsExpensify Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videosundefined

Uh oh!

MelvinBot commented Jul 2, 2026

Uh oh!

MelvinBot commented Jul 2, 2026

Uh oh!

Ollyws commented Jul 15, 2026

Uh oh!

melvin-bot Bot commented Jul 15, 2026

Uh oh!

MelvinBot commented Jul 15, 2026

Uh oh!

JmillsExpensify left a comment

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot Jul 15, 2026

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Jul 15, 2026

The failing build is a flaky iOS infra failure — not caused by this PR

Uh oh!

MelvinBot commented Jul 15, 2026

Uh oh!

melvin-bot Bot commented Jul 15, 2026

Uh oh!

MelvinBot commented Jul 15, 2026

The flaky iOS build is resolved — only the checklist remains

Uh oh!

MelvinBot commented Jul 15, 2026

The flaky iOS build is resolved — nothing left to fix in code

Uh oh!

lakchote commented Jul 16, 2026

Uh oh!

Ollyws commented Jul 20, 2026

Reviewer Checklist

Screenshots/Videos

Uh oh!

Ollyws commented Jul 20, 2026

Uh oh!

MelvinBot commented Sep 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ollyws commented Sep 14, 2026

Uh oh!

luacmartins left a comment

Choose a reason for hiding this comment

Uh oh!

Ollyws commented Sep 15, 2026

Uh oh!

MelvinBot commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ollyws commented Sep 15, 2026

Uh oh!

MelvinBot commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ollyws commented Sep 15, 2026

Uh oh!

MelvinBot commented Sep 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Ollyws commented Sep 15, 2026

Uh oh!

luacmartins left a comment

Choose a reason for hiding this comment

Uh oh!

MelvinBot commented Jul 2, 2026 •

edited by JmillsExpensify

Loading

MelvinBot commented Sep 14, 2026 •

edited

Loading

MelvinBot commented Sep 15, 2026 •

edited

Loading

MelvinBot commented Sep 15, 2026 •

edited

Loading

MelvinBot commented Sep 15, 2026 •

edited

Loading