[NoQA] Keep first Concierge send span alive across the thread switch by LukasMod · Pull Request #104240 · Expensify/App

LukasMod · 2026-10-16T14:54:13Z

Explanation of Change

Bug: with the respond-in-thread, the first message sent from the Concierge side panel always had its ManualSendMessageVisible span cancelled after about 200ms, before the message rendered.
Cause: sending calls openSidePanel({reportID: conciergeThreadReportID}) (useComposerSubmit.ts:150). SidePanelReport is not keyed, so the same ReportScreen gets a new reportID. The ReportLifecycleHandler cleanup then ran cancelAllSendMessageSpans(), which cancels every send span regardless of report. This started with "Open thread in sidepanel" (945f4678d5f4).
Fix: each send span records the report it will render in. For a respond-in-thread send that is the new thread, otherwise the composer's report (sendMessageSpans.ts:15, :25; useComposerSubmit.ts:116, :127). ReportLifecycleHandler now calls cancelSendMessageSpansForReport(onyxReportID) (ReportLifecycleHandler.tsx:55, sendMessageSpans.ts:103), which cancels only that report's spans and their phase spans.
SearchMoneyRequestReportPage is scoped the same way. Its unmount calls cancelSendMessageSpansForReport(reportIDFromRoute) (SearchMoneyRequestReportPage.tsx:246), and cancelAllSendMessageSpans is removed. A normal span end deletes its own map entry (sendMessageSpans.ts:84), and the sweep drops stale entries too (:109).
report_id and the other span attributes are unchanged, so Sentry queries keep working. The target report lives in a module-level map only

Could be related to this changes: #99317, deployed to production on Sep 16 with beta flag.

https://expensify.sentry.io/dashboard/9443290/?statsPeriod=30d

Fixed Issues

$ #104663
PROPOSAL:

Tests

Verify that no errors appear in the JS console

Test 1: Concierge side panel, first message

Open the Concierge side panel and send a message.
Confirm the span log, no cancelled attribute.

Test 2: Concierge side panel, follow-up in the thread

Send a second message in the same thread.
Confirm the span log, no cancelled attribute.

Test 3: Concierge chat in the main view, first message

Open the Concierge chat in the central pane and send a message.
Confirm the span log, no cancelled attribute.

Test 4: Regular chat

Send a message in a regular chat.
Confirm the span log, no cancelled attribute.

Test 5: Expense report in Search

Open an expense report from Search and add a comment.
Confirm the span log, no cancelled attribute.

Offline tests

QA Steps

Verify that no errors appear in the JS console

PR Author Checklist

Screenshots/Videos

Android: Native

Screen.Recording.2026-10-20.at.09.06.41.mov

Android: mWeb Chrome

iOS: Native

Screen.Recording.2026-10-19.at.17.00.50.mov

iOS: mWeb Safari

MacOS: Chrome / Safari

web.concierge.mov

codecov · 2026-10-16T14:59:43Z

Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

Files with missing lines	Coverage Δ
src/libs/telemetry/useSendMessageSpanMarks.ts	`71.42% <ø> (ø)`
src/pages/Search/SearchMoneyRequestReportPage.tsx	`90.90% <ø> (ø)`
src/pages/inbox/ReportLifecycleHandler.tsx	`100.00% <ø> (ø)`
...ox/report/ReportActionCompose/useComposerSubmit.ts	`79.31% <50.00%> (-1.40%)`	⬇️
src/libs/telemetry/sendMessageSpans.ts	`95.16% <91.30%> (-2.52%)`	⬇️
... and 16 files with indirect coverage changes

LukasMod · 2026-10-16T15:04:44Z

@MelvinBot review

MelvinBot · 2026-10-16T15:11:06Z

Review

The fix looks correct. Each send is now cancelled only by the report it renders in, so the side-panel thread switch no longer kills the first Concierge send. I found no blocking issues. CI checks pass, except the approval check.

Suggestions (non-blocking):

Scope the Search page cleanup too. SearchMoneyRequestReportPage.tsx:246 still calls cancelAllSendMessageSpans(). A Concierge side-panel send is still cancelled when the user closes or switches a Search expense report. On that page the composer uses the same route reportID (ReportFooter.tsx:62, :126). That means cancelSendMessageSpansForReport(reportIDFromRoute) should work there as well. If you found a case where the two IDs differ, a short comment at that call would help.
Map entries outlive normal span ends. useSendMessageSpanMarks.ts:21 ends the span with endSpan directly. The visibleReportIDBySpanID entry stays until the next report unmount sweeps it (sendMessageSpans.ts:100-102). The map stays small, so this is minor. Still, an endSendMessageVisibleSpan helper that also deletes the entry would keep start and end symmetric.

What I checked

The composer reportID and ReportLifecycleHandler's reportID both come from the route (ReportScreen.tsx:131, ReportFooter.tsx:126). Regular sends are still cancelled on unmount.
Moving generateReportID() above the span start does not change behavior. It still runs only when shouldRespondInThread is true.
In the central pane, addComment navigates to the thread only after Onyx.update resolves (Report/index.ts:1271-1277). The row also renders in the Concierge chat, so the span can end there. If the user leaves the thread first, the new test case covers the cancel.
activeSpans has no timeout. Any orphaned ManualSendMessageVisible span would also make getUniqueSpanByPrefix in OnyxDerived/index.ts:135 return undefined. I found no path that leaves a handed-off span orphaned.
The span attributes are unchanged, so the report_id filter in useCancelSendMessageSpanOnSkeleton and the Sentry queries keep working.

view run

…an end

LukasMod · 2026-10-20T08:50:49Z

@MelvinBot test

MelvinBot · 2026-10-20T09:09:44Z

🤖 Web test steps verification results: ⚠️ partial

All five sends worked in the UI with no visible errors. I couldn't confirm the main check, though. The web test tooling can't read the browser JS console, so I couldn't see whether the ManualSendMessageVisible span logs carry a cancelled attribute. Each step below is unverified, not failed.

Step	Status
1. Concierge side panel, first message: span log has no cancelled attribute The message sent and Concierge started replying. The test account's Help side panel opened the #admins room, where Concierge posts, not a Concierge DM. I couldn't check the console span log.	⚠️
2. Concierge side panel, follow-up in the thread: span log has no cancelled attribute The second message sent and Concierge replied. I couldn't check the console span log.	⚠️
3. Concierge chat in the central pane, first message: span log has no cancelled attribute I opened Expensify Concierge from the Inbox and sent a message. It appeared and Concierge started replying. I couldn't check the console span log.	⚠️
4. Regular chat: span log has no cancelled attribute The message sent in a chat without Concierge. I couldn't check the console span log.	⚠️
5. Expense report from Search, add a comment: span log has no cancelled attribute I created a $25.00 expense, opened it from the Expenses list, and posted a comment. I couldn't check the console span log.	⚠️
6. No errors appear in the JS console I saw no error banners, red indicators, or failure toasts in the UI. I couldn't read the JS console itself.	⚠️

To check the span itself, run these steps locally with devtools open, or check the Sentry dashboard after deploy.

view run · view recording

chatgpt-codex-connector · 2026-10-22T06:31:45Z

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	⚠️ Failed 2026-10-22T07:11:59.422498Z We couldn’t complete this review. Comment `@codex review` to try again.	`cb08a1b`	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

melvin-bot · 2026-10-22T06:32:14Z

@mjasikowski 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]

mjasikowski · 2026-10-22T08:01:15Z


 const SEND_MESSAGE_VISIBLE_PREFIX = `${CONST.TELEMETRY.SPAN_SEND_MESSAGE_VISIBLE}_`;

+// Report each in-flight send renders in, keyed by parent span id. A Concierge respond-in-thread send renders in the new thread, not in the chat it was typed in.


Report each in-flight send renders in

Can you convert this to human language please? 😄

Fair 😄, reworded!

dylanexpensify

@LukasMod mind confirming this comment:

The remaining gap is validation: the web test used a different chat and couldn’t inspect span cancellation attributes. Before calling it fully verified, I’d confirm a first Concierge respond-in-thread send finishes

LukasMod · 2026-10-22T14:06:33Z

@dylanexpensify
Verified on web with both fresh and older accounts. The first send from the Concierge side panel now ends normally, with no canceled attribute, and the message is visible in the new thread when the span ends. The test videos in the PR body show the span attributes.
I also tried to break it with a 6x CPU slowdown, a fresh user, and Concierge open in both the central view and the side panel. Every span ended cleanly, with no canceled or canceled_by_skeleton.

mjasikowski · 2026-10-23T19:31:07Z

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.
If the PR adds or modifies the UI:
- I asked an AI agent to review the changes for accessibility issues and addressed its findings.
- I tested with a screen reader (VoiceOver on macOS) and verified all new/changed elements are reachable with a logical focus order.
- I verified all new/changed elements have meaningful accessible names and roles.
- I verified state changes are announced (e.g. checked/unchecked, expanded/collapsed, selected).
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

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

…read-send-span-cancel

OSBotify · 2026-10-27T08:49:33Z

✋ 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-10-27T08:52:09Z

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

github-actions · 2026-10-27T08:59:44Z

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #104240 with the pinned Mobile-Expensify submodule.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-1279b3ec-8840fe4-974535b8d873e8340ea822aae64d6fdbfe08f780/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-1279b3ec-8840fe4-cdd4ce6377e090b85c90b53488a644a50b5f2334/index.html

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

👀 View the workflow run that generated this build 👀

OSBotify · 2026-10-27T22:09:48Z

🚀 Deployed to staging by https://github.com/mjasikowski in version: 9.5.24-1 🚀

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

MelvinBot · 2026-10-27T22:13:24Z

No help site update is needed. This PR only changes internal Sentry performance spans for sent messages, and users see no change in the app.

view run

OSBotify · 2026-10-29T00:57:20Z

🚀 Deployed to production by https://github.com/jasperhuangg in version: 9.5.24-8 🚀

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

Bundle Size Analysis (Sentry):

Android
iOS

melvin-bot Bot assigned LukasMod Oct 16, 2026

LukasMod mentioned this pull request Oct 16, 2026

[Metrics] Investigate remaining ~1-2s ManualSendMessage spans #95584

Closed

LukasMod force-pushed the LukasMod/concierge-thread-send-span-cancel branch from 83dde6c to f02d2b9 Compare October 19, 2026 14:57

LukasMod added 3 commits October 20, 2026 09:17

Keep first Concierge send span alive across the thread switch

7c3564a

Scope Search send span cleanup to its report and drop map entry on sp…

5558d50

…an end

Drop unused getSendMessageVisibleSpanID export to clear knip finding

cb08a1b

LukasMod force-pushed the LukasMod/concierge-thread-send-span-cancel branch from f02d2b9 to cb08a1b Compare October 20, 2026 07:19

Julesssss mentioned this pull request Oct 21, 2026

First Concierge side panel message cancels its ManualSendMessageVisible span #104663

Closed

LukasMod marked this pull request as ready for review October 22, 2026 06:31

LukasMod requested review from a team as code owners October 22, 2026 06:31

melvin-bot Bot requested a review from dylanexpensify October 22, 2026 06:31

melvin-bot Bot requested review from mjasikowski and removed request for a team October 22, 2026 06:31

mjasikowski reviewed Oct 22, 2026

View reviewed changes

dylanexpensify reviewed Oct 22, 2026

View reviewed changes

Reword visible report map comment in plain language

79cf300

mjasikowski approved these changes Oct 23, 2026

View reviewed changes

LukasMod changed the title ~~[NoQA] Keep first Concierge send span alive across the thread switch~~ [NoQA] Keep first Concierge send span alive across the thread switch Oct 27, 2026

LukasMod changed the title ~~[NoQA] Keep first Concierge send span alive across the thread switch~~ [NoQA] Keep first Concierge send span alive across the thread switchh Oct 27, 2026

LukasMod changed the title ~~[NoQA] Keep first Concierge send span alive across the thread switchh~~ [NoQA] Keep first Concierge send span alive across the thread switch Oct 27, 2026

Merge remote-tracking branch 'origin/main' into LukasMod/concierge-th…

4ac28a2

…read-send-span-cancel

mjasikowski merged commit 1279b3e into Expensify:main Oct 27, 2026
34 checks passed

OSBotify mentioned this pull request Oct 27, 2026

Deploy Checklist: New Expensify 2026-10-27 #105183

Closed

97 tasks done


		const SEND_MESSAGE_VISIBLE_PREFIX = `${CONST.TELEMETRY.SPAN_SEND_MESSAGE_VISIBLE}_`;

		// Report each in-flight send renders in, keyed by parent span id. A Concierge respond-in-thread send renders in the new thread, not in the chat it was typed in.

Conversation

LukasMod commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation of Change

Fixed Issues

Tests

Test 1: Concierge side panel, first message

Test 2: Concierge side panel, follow-up in the thread

Test 3: Concierge chat in the main view, first message

Test 4: Regular chat

Test 5: Expense report in Search

Offline tests

QA Steps

PR Author Checklist

Screenshots/Videos

Uh oh!

codecov Bot commented Oct 16, 2026 • edited by github-actions Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

LukasMod commented Oct 16, 2026

Uh oh!

MelvinBot commented Oct 16, 2026

Review

Uh oh!

LukasMod commented Oct 20, 2026

Uh oh!

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

Uh oh!

Uh oh!

chatgpt-codex-connector Bot commented Oct 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codex Review Summary

Uh oh!

melvin-bot Bot commented Oct 22, 2026

Uh oh!

mjasikowski Oct 22, 2026

Choose a reason for hiding this comment

Uh oh!

LukasMod Oct 22, 2026

Choose a reason for hiding this comment

Uh oh!

dylanexpensify left a comment

Choose a reason for hiding this comment

Uh oh!

LukasMod commented Oct 22, 2026

Uh oh!

mjasikowski commented Oct 23, 2026

Reviewer Checklist

Screenshots/Videos

Uh oh!

Uh oh!

OSBotify commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

github-actions Bot commented Oct 27, 2026

Uh oh!

OSBotify commented Oct 27, 2026

Uh oh!

MelvinBot commented Oct 27, 2026

Uh oh!

OSBotify commented Oct 29, 2026

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

LukasMod commented Oct 16, 2026 •

edited

Loading

codecov Bot commented Oct 16, 2026 •

edited by github-actions Bot

Loading

MelvinBot commented Oct 20, 2026 •

edited

Loading

chatgpt-codex-connector Bot commented Oct 22, 2026 •

edited

Loading