You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Concierge - Feedback prompt is not shown when the message is opened in thread #101673
Version Number: 9.4.90-0 Reproducible in staging?: Yes Reproducible in production?: N/A - new feature, doesn't exist in prod If this was caught during regression testing, add the test name, ID and link from BrowserStack: - Email or phone of affected tester (no customers):jsdoijnodsdisojo@gmail.com Issue reported by: Applause Internal Team Bug source: Exploratory - Significant User Experience Deterioration Device used: Mac 26.5 / Chrome App Component: Chat Report View
Action Performed:
Go to staging.new.expensify.com
Go to Concierge chat.
Right click on message from Concierge that has feedback prompt.
Click Reply in thread.
Expected Result:
Feedback prompt will be shown when the message is opened in thread.
Actual Result:
Feedback prompt is not shown when the message is opened in thread.
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
Identify the pull request that introduced this issue and revert it.
The Concierge feedback prompt is a brand-new, non-production feature from a single PR that has already produced more than one deploy blocker, and nothing merged after it depends on it, so reverting #100454 is cleaner and lower risk than patching the thread/ancestor render path under deploy pressure. If the team prefers to roll forward, the targeted fix is described in the Root Cause section below.
Assigned: @oqildev (PR author), @yuwenmemon (approving reviewer) from highest-confidence causing PR only Labels: No label changes. DeployBlockerCash is kept (App-side fix required); DeployBlocker was never applied.
📋 Detailed Analysis
Evidence
The feedback prompt (Was that response useful? 👍 👎) is introduced entirely by #100454, merged 2026-09-18, which is on the open checklist Deploy Checklist: New Expensify 2026-09-18 (Expensify/App#101620).
The issue reports "N/A - new feature, doesn't exist in prod", which matches a feature that first shipped in this staging release. Reproducible on staging only.
That PR added ConciergeFeedbackPrompt, getLatestConciergeFeedbackActionID, and the isLatestConciergeFeedbackAction prop chain. No other PR in the checklist touches Concierge feedback, and no PR merged after it modifies this code, so a revert should apply cleanly.
git log on the App checkout confirms these files carry the feature, and gh pr view 100454 --json files lists every one of them except AncestorReportActionItem.tsx.
Root Cause
The prompt is gated on a single boolean, isLatestConciergeFeedbackAction, which is only ever computed by a list container and only ever passed down one of the render paths that reach ReportActionItem.
In ReportActionsList.tsx#L336-L339 the flag is derived from renderedVisibleReportActions, i.e. only the actions belonging to the currently open report. When you open a thread, the currently open report is the thread, and the Concierge message you rated is the thread's parent, which is not in that array. So getLatestConciergeFeedbackActionID cannot select it.
ReportActionItem has five call sites in src/. #100454 handled the main list and accounted for search (via isOnSearch) and the money-request report list, but the thread-parent/ancestor path was missed.
Targeted fix, if rolling forward is preferred: thread eligibility through the parent path — compute whether the parent action qualifies (using the parent report's actions and its conciergeFeedbackForReportActionID NVP, not the thread's) and pass isLatestConciergeFeedbackAction from ReportActionItemParentAction → AncestorReportActionItem → ReportActionItem. Note this is meaningfully more than prop-drilling: the eligibility data currently lives in the wrong report's scope, which is why a revert is the safer deploy-blocker resolution. Alternatively, if hiding the prompt on a thread parent is acceptable product behaviour, this could be demoted — but that is a product call, not something I can conclude from the code.
💡 Suggested AI code review rule
This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for Expensify/App:
Rule:CONSISTENCY-18 Wire new ReportActionItem display props through every render path
Condition: When a PR adds a new display/behaviour prop to ReportActionItem (or to anything it renders, such as ActionContentRouter / ChatMessageContent), it must pass that prop at every<ReportActionItem call site — the main list renderer, the thread-parent/ancestor path, the money-request report list, and the search list — or explicitly document why a path is exempt. Flag any PR that adds a prop at one call site only.
Why: A report action is rendered through several independent entry points. Wiring a new prop into only one of them makes the feature silently vanish in the other contexts and the default value (usually false) hides the failure instead of surfacing it — exactly what happened here, where the Concierge feedback prompt disappears as soon as the same message is viewed as a thread parent. Incident: Concierge - Feedback prompt is not shown when the message is opened in thread (Expensify/App#101673).
Search pattern:grep -rn "<ReportActionItem" src/ to enumerate the call sites, then check the new prop name appears at each one (currently: ReportActionsListItemRenderer.tsx, AncestorReportActionItem.tsx, ChatListItem.tsx, and the two pages/Debug/ReportAction/ previews).
The full rule file, with the ❌/✅ code inline in Expensify/App's app-coding-standards format, would go in Expensify/App itself. If it's worth adding, a maintainer can open it there as a draft PR.
@yuwenmemon@mountiny
The prompt is computed in the actions list, and the message at the top of a thread is rendered through a different path that never receives that flag, which is why it's missing there. Before I change it: should the prompt show on the parent message inside a thread, given the same message already shows it in the chat itself?
Happy to do it either way, cc @Expensify/design.
Activity
applause-bot commentedon Sep 21, 2026
While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/495bddb342746644307da1408fe4203f0b3eec2def3499cd5aa4624270944b99
melvin-bot commentedon Sep 21, 2026
Triggered auto assignment to @mountiny (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.melvin-bot commentedon Sep 21, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Sep 21, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
MelvinBot commentedon Sep 21, 2026
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: feat: add 👍/👎 feedback prompt under the latest Concierge response (
Expensify/App#100454) - by @oqildev (High confidence)Related Issues: ["Thanks for the feedback!" is not shown on both chats when both Concierge chats are opened] (
Expensify/App#101672) — same PR, same featureRecommendation: REVERT
The Concierge feedback prompt is a brand-new, non-production feature from a single PR that has already produced more than one deploy blocker, and nothing merged after it depends on it, so reverting #100454 is cleaner and lower risk than patching the thread/ancestor render path under deploy pressure. If the team prefers to roll forward, the targeted fix is described in the Root Cause section below.
Assigned: @oqildev (PR author), @yuwenmemon (approving reviewer) from highest-confidence causing PR only
Labels: No label changes.
DeployBlockerCashis kept (App-side fix required);DeployBlockerwas never applied.📋 Detailed Analysis
Evidence
Was that response useful? 👍 👎) is introduced entirely by #100454, merged 2026-09-18, which is on the open checklist Deploy Checklist: New Expensify 2026-09-18 (Expensify/App#101620).ConciergeFeedbackPrompt,getLatestConciergeFeedbackActionID, and theisLatestConciergeFeedbackActionprop chain. No other PR in the checklist touches Concierge feedback, and no PR merged after it modifies this code, so a revert should apply cleanly.Verification
Files owned by the bug, all touched by #100454:
src/pages/inbox/report/ReportActionsList.tsx#L336-L339— computeslatestConciergeFeedbackActionIDsrc/pages/inbox/report/ReportActionsListItemRenderer.tsx#L151-L186— branches between the parent-action path andReportActionItemsrc/pages/inbox/report/AncestorReportActionItem.tsx#L154-L167— the thread parent render path (not touched by the PR — this is the gap)src/pages/inbox/report/actionContents/ChatMessageContent.tsx#L128-L133— renders the promptgit logon the App checkout confirms these files carry the feature, andgh pr view 100454 --json fileslists every one of them exceptAncestorReportActionItem.tsx.Root Cause
The prompt is gated on a single boolean,
isLatestConciergeFeedbackAction, which is only ever computed by a list container and only ever passed down one of the render paths that reachReportActionItem.In
ReportActionsList.tsx#L336-L339the flag is derived fromrenderedVisibleReportActions, i.e. only the actions belonging to the currently open report. When you open a thread, the currently open report is the thread, and the Concierge message you rated is the thread's parent, which is not in that array. SogetLatestConciergeFeedbackActionIDcannot select it.Even if it could, the parent message in a thread is not rendered through the
ReportActionItembranch that receives the prop.ReportActionsListItemRenderer.tsx#L151-L165short-circuits for the thread'sCREATEDaction intoReportActionItemParentAction→AncestorReportActionItem, andAncestorReportActionItem.tsx#L154-L167rendersReportActionItemwithoutisLatestConciergeFeedbackAction. It therefore falls back to the defaultfalseatReportActionItem.tsx#L175, andChatMessageContent.tsx#L128never renders the prompt.ReportActionItemhas five call sites insrc/. #100454 handled the main list and accounted for search (viaisOnSearch) and the money-request report list, but the thread-parent/ancestor path was missed.Targeted fix, if rolling forward is preferred: thread eligibility through the parent path — compute whether the parent action qualifies (using the parent report's actions and its
conciergeFeedbackForReportActionIDNVP, not the thread's) and passisLatestConciergeFeedbackActionfromReportActionItemParentAction→AncestorReportActionItem→ReportActionItem. Note this is meaningfully more than prop-drilling: the eligibility data currently lives in the wrong report's scope, which is why a revert is the safer deploy-blocker resolution. Alternatively, if hiding the prompt on a thread parent is acceptable product behaviour, this could be demoted — but that is a product call, not something I can conclude from the code.💡 Suggested AI code review rule
This bug looks like a recurring, mechanically detectable pattern, so it may be worth a coding-standards rule so the AI reviewer catches the next one. Proposed for
Expensify/App:CONSISTENCY-18Wire newReportActionItemdisplay props through every render pathReportActionItem(or to anything it renders, such asActionContentRouter/ChatMessageContent), it must pass that prop at every<ReportActionItemcall site — the main list renderer, the thread-parent/ancestor path, the money-request report list, and the search list — or explicitly document why a path is exempt. Flag any PR that adds a prop at one call site only.false) hides the failure instead of surfacing it — exactly what happened here, where the Concierge feedback prompt disappears as soon as the same message is viewed as a thread parent. Incident: Concierge - Feedback prompt is not shown when the message is opened in thread (Expensify/App#101673).grep -rn "<ReportActionItem" src/to enumerate the call sites, then check the new prop name appears at each one (currently:ReportActionsListItemRenderer.tsx,AncestorReportActionItem.tsx,ChatListItem.tsx, and the twopages/Debug/ReportAction/previews).AncestorReportActionItem.tsx#L154-L167— rendersReportActionItemwith noisLatestConciergeFeedbackActionReportActionsListItemRenderer.tsx#L167-L186already doesThe full rule file, with the ❌/✅ code inline in
Expensify/App'sapp-coding-standardsformat, would go inExpensify/Appitself. If it's worth adding, a maintainer can open it there as a draft PR.melvin-bot commentedon Sep 21, 2026
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
oqildev commentedon Sep 21, 2026
@yuwenmemon @mountiny
The prompt is computed in the actions list, and the message at the top of a thread is rendered through a different path that never receives that flag, which is why it's missing there. Before I change it: should the prompt show on the parent message inside a thread, given the same message already shows it in the chat itself?
Happy to do it either way, cc @Expensify/design.
39 remaining items
melvin-bot commentedon Oct 20, 2026
@eVoloshchak Eep! 4 days overdue now. Issues have feelings too...
melvin-bot commentedon Oct 22, 2026
@eVoloshchak Still overdue 6 days?! Let's take care of this!
eVoloshchak commentedon Oct 26, 2026
Not overdue
melvin-bot commentedon Oct 29, 2026
@eVoloshchak Whoops! This issue is 2 days overdue. Let's get this updated quick!
eVoloshchak commentedon Nov 2, 2026
Not overdue
melvin-bot commentedon Nov 5, 2026
@eVoloshchak Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!
eVoloshchak commentedon Nov 9, 2026
Witing for #102824
melvin-bot commentedon Nov 12, 2026
@eVoloshchak Whoops! This issue is 2 days overdue. Let's get this updated quick!