Skip to content

Concierge - Feedback prompt is not shown when the message is opened in thread #101673

Open

Description

@applause-bot

If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form.


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:

  1. Go to staging.new.expensify.com
  2. Go to Concierge chat.
  3. Right click on message from Concierge that has feedback prompt.
  4. 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.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7263636_1789770663023.5.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Mita Rachim
Bug ID: 7263636

Issue OwnerCurrent Issue Owner: @eVoloshchak

Activity

  1. added
    DeployBlockerCashThis issue or pull request should block deployment
    BugSomething is broken. Auto assigns a BugZero manager.
    on Sep 21, 2026
  2. applause-bot commented on Sep 21, 2026

    @applause-bot
    Author

    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

  3. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    Triggered auto assignment to @mountiny (DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.

  4. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    💬 A slack conversation has been started in #expensify-open-source

  5. github-actions commented on Sep 21, 2026

    @github-actions
    Contributor

    👋 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:

    1. Identify the pull request that introduced this issue and revert it.
    2. Find someone who can quickly fix the issue.
    3. Fix the issue yourself.
  6. MelvinBot commented on Sep 21, 2026

    @MelvinBot
    Contributor

    🔍 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 feature

    Recommendation: 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. 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.

    Verification

    Files owned by the bug, all touched by #100454:

    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.

    1. 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.

    2. Even if it could, the parent message in a thread is not rendered through the ReportActionItem branch that receives the prop. ReportActionsListItemRenderer.tsx#L151-L165 short-circuits for the thread's CREATED action into ReportActionItemParentAction → AncestorReportActionItem, and AncestorReportActionItem.tsx#L154-L167 renders ReportActionItem without isLatestConciergeFeedbackAction. It therefore falls back to the default false at ReportActionItem.tsx#L175, and ChatMessageContent.tsx#L128 never renders the prompt.

    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).
    • Offending code (❌): AncestorReportActionItem.tsx#L154-L167 — renders ReportActionItem with no isLatestConciergeFeedbackAction
    • Fix (✅): pass the flag here the way ReportActionsListItemRenderer.tsx#L167-L186 already does

    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.

  7. melvin-bot commented on Sep 21, 2026

    @melvin-bot

    ⚠️ Looks like this issue was linked to a Deploy Blocker here

    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.

  8. oqildev commented on Sep 21, 2026

    @oqildev
    Contributor

    @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.

  9. removed their assignment
    on Sep 21, 2026
  10. 39 remaining items

  11. melvin-bot commented on Oct 20, 2026

    @melvin-bot

    @eVoloshchak Eep! 4 days overdue now. Issues have feelings too...

  12. melvin-bot commented on Oct 22, 2026

    @melvin-bot

    @eVoloshchak Still overdue 6 days?! Let's take care of this!

  13. eVoloshchak commented on Oct 26, 2026

    @eVoloshchak
    Contributor

    Not overdue

  14. melvin-bot commented on Oct 29, 2026

    @melvin-bot

    @eVoloshchak Whoops! This issue is 2 days overdue. Let's get this updated quick!

  15. eVoloshchak commented on Nov 2, 2026

    @eVoloshchak
    Contributor

    Not overdue

  16. melvin-bot commented on Nov 5, 2026

    @melvin-bot

    @eVoloshchak Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

  17. eVoloshchak commented on Nov 9, 2026

    @eVoloshchak
    Contributor

    Witing for #102824

  18. melvin-bot commented on Nov 12, 2026

    @melvin-bot

    @eVoloshchak Whoops! This issue is 2 days overdue. Let's get this updated quick!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

BugSomething is broken. Auto assigns a BugZero manager.DailyKSv2EngineeringOverdueSkip PaymentSkips all the payment process steps for an issue. Use it for fixed-price projects.

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions