[Due for payment 2026-05-22] [Due for payment 2026-05-20] [$250] Chat - Draft message is sent after saving message edit

[jponikarchuk]

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: 9.3.73-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #76741
Email or phone of affected tester (no customers): sdsdjoijdoisnjodis@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 15 Pro Max / iOS 26.4.2
App Component: Chat Report View

Action Performed:

1. Launch Expensify app.
2. Open any chat.
3. Send a message.
4. Type anything on the composer but do not send it.
5. Long tap on the sent message in Step 3 > Edit comment.
6. Edit the message and save it.

Expected Result:

Draft message will remain on the composer.

Actual Result:

Draft message is sent after saving message edit.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @hungvu193

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022054547794256942348
• Upwork Job ID: 2054547794256942348
• Last Price Increase: 2026-05-13

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #76741

[melvin-bot]

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

[github-actions]

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

[OSBotify]

Investigation Summary

Classification: Frontend bug
Causing PR: #76741 - "New editing mechanism for small screens" by @Kureev (High confidence)
Related Issues: #64085 (the issue this PR was fixing)

Recommendation: REVERT

The new editing mechanism introduced in PR #76741 contains a logic flaw that causes the draft message in the composer to be sent as a new message when saving a message edit on narrow (mobile) layouts.

Assigned: @Kureev (PR author), @adhorodyski, @hungvu193, @mountiny (approving reviewers)
Labels: DeployBlockerCash kept (Frontend bug in App PR). No label changes required.

Detailed Analysis

Evidence

• The bug is staging-only (version 9.3.73-0), which aligns with PR New editing mechanism for small screens #76741 merging on 2026-05-12 — the day before the staging deploy.
• The bug affects Android and iOS native apps only (not mWeb), which is consistent with the narrow-layout code path this PR introduced.
• The melvin-bot also identified PR New editing mechanism for small screens #76741 as the likely cause.
• PR New editing mechanism for small screens #76741 fundamentally redesigned the message editing flow on narrow (mobile) layouts, replacing inline editing with a "composer-based" editing mode.

Verification

The PR modifies the following files that are directly involved in the bug:

• src/pages/inbox/report/ReportActionCompose/ComposerInput.tsx — wires onClear to validateAndSubmitDraft
• src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx — defines clearWorklet and onClear callback
• src/pages/inbox/report/ReportActionCompose/useComposerSubmit.ts — contains submitDraftAndClearComposer and validateAndSubmitDraft
• src/pages/inbox/report/ReportActionCompose/ComposerProvider.tsx — defines clearComposer which calls clearWorklet

All of these files were introduced or significantly modified by PR #76741, and all are confirmed present in the repo at those paths.

Root Cause

In ComposerInput.tsx line 99, the onClear prop on ComposerWithSuggestions is wired to validateAndSubmitDraft:

onClear = { validateAndSubmitDraft };

In ComposerWithSuggestions.tsx, the onClear callback is invoked from the clearWorklet path (via forceClearInput), which passes the current text value at the time of clearing:

const onClear = useCallback(
  (text: string) => {
    mobileInputScrollPosition.current = 0;
    onClearProp(text); // <-- calls validateAndSubmitDraft(text)
    updateComment("", true);
  },
  [onClearProp, updateComment],
);

In useComposerSubmit.ts, the submitDraftAndClearComposer function handles the submit-and-save-edit flow. When isEditingInComposer is true and there is a draftComment, it calls validateAndSubmitDraft(editingMessage) directly and returns early — correctly saving the edit. But then it also calls clearComposer() to clear the input on the UI thread. That clearComposer call triggers clearWorklet, which fires onClear(text) where text is the draft comment value from the composer at that moment, resulting in validateAndSubmitDraft(draftComment) being invoked a second time. At this point isEditingInComposer has been cleared, so the second call falls through to the addComment path and sends the draft as a new message.

The fix likely needs to either: (a) not call clearComposer when finishing an edit in the composer, or (b) gate validateAndSubmitDraft from onClear when we are in an edit-finishing flow. Given the complexity of the changes in this PR, a revert is the safest option to unblock the deploy.