[$250] iOS - Chat - Sent message remains in the compose box after returning to the chat from Search

[applause-bot]

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.4.15-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #92938
Email or phone of affected tester (no customers): jsat@applausemail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: iPhone 13 mini/18.6.2
App Component: Other

Action Performed:

1. Launch Expensify App
2. Log in with valid credentials
3. Open Search
4. Open a recent chat
5. Type and send a message
6. Go back using the top back button or swipe-back gesture
7. Open the same chat again from Search

Expected Result:

The compose box should be empty after the message has been successfully sent.

Actual Result:

When reopening the chat from Search, the previously sent message is still displayed in the compose box as if it were an unsent draft.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Bug7186008_1781924363776.iOS-Repro.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7186008

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022068322912791692610
• Upwork Job ID: 2068322912791692610
• Last Price Increase: 2026-06-20

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/a5cefd79568d289201b43c44b8e7ce8ac88cf1927337b99119d75e71fdee448f

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After sending a message and quickly navigating back, reopening the same chat from Search shows the just-sent message still sitting in the compose box as if it were an unsent draft.

What is the root cause of that problem?

The draft is cleared on send through a 1000 ms debounced Onyx write, and that pending write is canceled (not flushed) when the screen unmounts — and opening a report from Search always remounts the report screen, which re-reads the stale Onyx draft.

Step by step:

1. On send, the composer clears the native input and calls updateComment('', true). The true flag routes the clear through the debounced save path instead of an immediate one (ComposerWithSuggestions.tsx:559-563), so clearing the persisted draft is deferred by DRAFT_SAVE_DEBOUNCE_TIME = 1000 ms.
2. If the user navigates back within that 1 s window, the composer unmounts and useDebounce's cleanup calls debouncedFn.cancel(), dropping the pending "clear draft" write. The Onyx key REPORT_DRAFT_COMMENT{reportID} keeps the sent text.
3. Opening the chat from Search uses RHPReportScreen, which mounts ReportScreen with key={reportID} — forcing a full remount every time. On mount the composer re-initializes its text from the Onyx draft (ComposerProvider.tsx:54-58), so the stale draft reappears in the box.

This is why it reproduces reliably from Search but not from the LHN: the LHN report screen stays mounted, so its in-memory (already-cleared) composer state masks the stale Onyx draft.

Note: PR #92938 referenced in the report is "perf: search autocomplete optimization" — it only touches Search autocomplete files and does not change composer/draft logic. The bug was caught during regression testing of that PR, but this is a pre-existing timing bug, not a regression introduced by it.

What changes do you think we should make in order to solve the problem?

Clear the persisted draft synchronously on send rather than via the debounced path. In the clear-on-send handler (ComposerWithSuggestions.tsx onClear), the empty clear should not be debounced — e.g. call updateComment('', false) (immediate saveReportDraftComment(reportID, '')) instead of updateComment('', true). There is no reason to debounce clearing on a send, and an immediate write closes the race entirely.

Alternative solutions considered

• Flush instead of cancel on unmount — flush the pending debounced draft save in useDebounce's cleanup. This fixes the issue more broadly (any unmount-before-debounce case), but changes shared debounce behavior used elsewhere, so it's riskier than the targeted fix above.
• Clear the Onyx draft in the send action itself (addComment). addComment/addActions in Report/index.ts currently don't touch REPORT_DRAFT_COMMENT at all, so the client composer is solely responsible. Clearing it there would also be robust, but it's a larger change than the composer-side fix.

Confidence: High — code evidence forms a complete chain (debounced clear → canceled on unmount → keyed remount re-reads stale Onyx draft), and it explains why Search reproduces while LHN does not. This is a deterministic client-side lifecycle/timing bug, so production logs would not add confirmation.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/94118) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[MobileMage]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a chat is opened from Search on iOS, a message is sent, and the user immediately goes back (top back button or swipe-back), reopening that same chat from Search shows the just-sent message still sitting in the compose box as if it were an unsent draft. The compose box should be empty after a successful send.

What is the root cause of that problem?

Sending a message and clearing the draft are wired through the composer's native onClear event. When you press Enter/Send, submitDraftAndClearComposer calls clearComposer(), which dispatches a UI-thread clear command on the native input (forceClearInput). That fires the composer's onClear, and in ComposerWithSuggestions the handler both sends the message and clears the draft:

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 963 to 971 in cc90dd2

	const onClear = useCallback(
	(textOnClear: string) => {
	mobileInputScrollPosition.current = 0;
	// Note: use the value when the clear happened, not the current value which might have changed already
	onClearProp(textOnClear);
	updateComment('', true);
	},
	[onClearProp, updateComment],
	);

The send (onClearProp → validateAndSubmitDraft → addComment) happens synchronously, but the draft clear goes through updateComment('', true). The true flag routes the Onyx write through the debounced path, so the actual saveReportDraftComment(reportID, '') (an Onyx.merge(..., null) that deletes the draft key) is scheduled ~1000ms later (DRAFT_SAVE_DEBOUNCE_TIME):

if (shouldDebounceSaveComment) {
    debouncedSaveComment(newCommentConverted); // <- '' here, deferred 1s via lodash debounce
} else {
    saveReportDraftComment(reportID, newCommentConverted);
}

Critically, addComment/addActions in src/libs/actions/Report/index.ts never touch REPORT_DRAFT_COMMENT — the only place the draft is cleared on send is that debounced write. The debounce is created with useDebounce, whose cleanup runs debouncedFn.cancel() on unmount. From Search, the chat is rendered inside the SEARCH_REPORT RHP (RHPReportScreen), and going back dismisses the RHP and unmounts the composer almost immediately — well within the 1s window. The unmount cancels the pending saveReportDraftComment(reportID, ''), so the draft key in Onyx is never cleared and still holds the sent text. On reopen, ComposerProvider seeds its text state from that stale Onyx draft via getInitialText() (draftComment ?? ''), so the sent message reappears in the box. This is why it surfaces on the Search path (fast unmount on back) rather than normal LHN navigation, and why it reproduces in production too — PR #92938 only made it easier to hit.

What changes do you think we should make in order to solve the problem?

Clear the draft synchronously when the user deliberately sends/clears, instead of through the cancelable debounce. In the onClear handler of ComposerWithSuggestions, switch the clear to the non-debounced branch:

const onClear = useCallback((textOnClear: string) => {
    mobileInputScrollPosition.current = 0;
    onClearProp(textOnClear);
    updateComment('', false); // was: updateComment('', true)
}, [onClearProp, updateComment]);

With false, updateComment takes the immediate saveReportDraftComment(reportID, '') path, persisting the empty-draft (key deletion) to Onyx before any back-navigation can unmount the composer and cancel a pending debounce. This is safe because onClear only fires for an explicit submit/clear (the native clear command is dispatched solely from clearComposer() in the submit flow), not on keystrokes, so we are not removing debouncing from the normal typing path that it exists to protect. To also neutralize a still-pending debounced save of the last keystroke's text (which could otherwise re-persist after we clear), useDebouncedSaveDraft should expose a cancel and we call it in onClear before the immediate write — mirroring the existing flush()-on-submit pattern already used for debouncedCommentMaxLengthValidation in submitDraftAndClearComposer.

What alternative solutions did you explore? (Optional)

Flushing the debounced save on navigation blur in ComposerWithSuggestions (via the existing navigation blur listener) would also persist the clear before unmount, but it is broader and timing-dependent — it relies on the blur firing before the debounce is cancelled and would flush mid-edit drafts too; clearing synchronously at the single deliberate send/clear point is the minimal, deterministic fix.

[ahmdshrif]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After sending a message, opening Search and returning to the chat, the just-sent message reappears in the compose box as if it were an unsent draft, instead of an empty composer.

What is the root cause of that problem?

The composer seeds its initial text from the persisted Onyx draft on mount: initialText = effectiveDraft ?? text (CWS L270-L276). So clearing the composer after send must actually persist '' to that Onyx draft, or it re-seeds on remount.

On send, both the message-send and the draft-clear run inside the native clear event: pressing send/enter triggers the worklet clear (forceClearInput native), whose onClear callback both sends the message (onClearProp) and clears the draft via updateComment('', true) (CWS L963-L970). The true routes the empty write through the debounced debouncedSaveComment('') instead of an immediate saveReportDraftComment (CWS L558-L563).

The structural cause: clearing-on-send is a terminal action but is treated like a keystroke (debounced 1000ms). On unmount, useDebounce cancel()s the still-pending save and discards it (useDebounce L31-L34). Returning via Search's back/swipe-back unmounts the narrow-layout report screen well within 1000ms, so '' never lands in Onyx; the previously-typed draft (saved earlier while typing) survives, and the remounted composer re-reads it. This explains every detail: message sends fine (onClear fired), only the draft stays, and it shows the prior text, not a duplicate.

What changes do you think we should make in order to solve the problem?

Make the clear-on-send write synchronous, since it fires in the same JS tick as the send. In onClear, pass false:

const onClear = useCallback((textOnClear: string) => {
    mobileInputScrollPosition.current = 0;
    onClearProp(textOnClear);
    updateComment('', false); // immediate saveReportDraftComment(reportID, '')
}, [onClearProp, updateComment]);

This persists the empty draft before any navigation can unmount the composer. Regression safety: only the clear-on-send path changes; normal typing still uses the debounced path, so keystroke save frequency is unchanged.

What alternative solutions did you explore? (Optional)

1. Flush (not cancel) pending draft saves on unmount in useDebouncedSaveDraft / useDebounce. Correct and also rescues typed-then-left drafts, but useDebounce powers many features (search, validation) — flushing all on unmount is a far wider blast radius.
2. Clear the draft inside the addComment action. Central, but the action is shared by many call sites and the draft is a composer concern — over-scoped for this bug.

[lorretheboy]

Proposal

What is the root cause of that problem?

Sending a message dispatches the message immediately, but clearing the draft from Onyx is debounced. When the composer is cleared on send, onClear calls updateComment('', true):

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 963 to 971 in cc90dd2

	const onClear = useCallback(
	(textOnClear: string) => {
	mobileInputScrollPosition.current = 0;
	// Note: use the value when the clear happened, not the current value which might have changed already
	onClearProp(textOnClear);
	updateComment('', true);
	},
	[onClearProp, updateComment],
	);

The true routes the empty value through the debounced saver instead of writing it right away:

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 559 to 563 in cc90dd2

	if (shouldDebounceSaveComment) {
	debouncedSaveComment(newCommentConverted);
	} else {
	saveReportDraftComment(reportID, newCommentConverted);
	}

That debounce waits DRAFT_SAVE_DEBOUNCE_TIME (1000ms), and on unmount it is cancelled, not flushed — both useDebouncedSaveDraft and the underlying useDebounce only cancel() on cleanup:

App/src/hooks/useDebounce.ts

Lines 32 to 35 in cc90dd2

	return () => {
	debouncedFn.cancel();
	};
	}, [func, wait, leading, maxWait, trailing]);

So the causal chain is: type "x" (draft x saved to Onyx) → send (message dispatched, empty-draft save scheduled but still pending) → go back within ~1s → the composer unmounts → the pending saveReportDraftComment('') is cancelled → Onyx REPORT_DRAFT_COMMENT still holds x. Reopening the chat re-seeds the composer from that stale draft:

App/src/pages/inbox/report/ReportActionCompose/ComposerProvider.tsx

Lines 54 to 58 in cc90dd2

	const getInitialText = () => {
	return draftComment ?? '';
	};
	const textRef = useRef<string>(getInitialText());
	const [text, setTextState] = useState(getInitialText);

The Search-from-back flow triggers this reliably because tapping a chat in Search and immediately swiping back unmounts the report screen well inside the 1s debounce window. (The referenced PR #92938 only swaps the autocomplete list for a skeleton on transitionEnd; it does not touch draft handling, so it surfaces the timing but is not where the defect lives.)

What changes do you think we should make in order to solve the problem?

Clear the draft synchronously when a message is sent, rather than debouncing it. In onClear, pass false so the empty value is written to Onyx immediately:

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 963 to 971 in cc90dd2

	const onClear = useCallback(
	(textOnClear: string) => {
	mobileInputScrollPosition.current = 0;
	// Note: use the value when the clear happened, not the current value which might have changed already
	onClearProp(textOnClear);
	updateComment('', true);
	},
	[onClearProp, updateComment],
	);

i.e. call updateComment('', false) (which routes to saveReportDraftComment(reportID, '')) instead of updateComment('', true). Debouncing is only useful while a user is actively typing; the clear-on-send is a single terminal write and should never be dropped by a later unmount. This guarantees the draft is gone regardless of how fast the user navigates away.

What alternative solutions did you explore? (Optional)

Flush (instead of cancel) any pending debounced draft save on composer unmount in useDebouncedSaveDraft / useDebounce. This also fixes it, but flushing on unmount is broader and could persist stale intermediate keystrokes in other flows, so the targeted synchronous clear-on-send is safer.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @gijoe0295 (External)

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After sending a message in a chat opened from Search, navigating back and reopening the same chat shows the just-sent message still sitting in the compose box, as if it were an unsent draft. The compose box should be empty once the message has been sent.

What is the root cause of that problem?

When a message is sent, the composer is cleared and the empty value is written back to the report's draft comment in Onyx. However, that write-back of the empty draft is debounced by 1 second, and the debounce is cancelled on unmount, so quickly leaving the chat before the second elapses drops the clear entirely and the previously typed text survives in Onyx as a stale draft.

The clear-on-send happens in onClear, which calls updateComment('', true) — the second argument true is shouldDebounceSaveComment:

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 963 to 970 in cc90dd2

	const onClear = useCallback(
	(textOnClear: string) => {
	mobileInputScrollPosition.current = 0;
	// Note: use the value when the clear happened, not the current value which might have changed already
	onClearProp(textOnClear);
	updateComment('', true);
	},
	[onClearProp, updateComment],

Inside updateComment, when shouldDebounceSaveComment is truthy the empty value is saved through debouncedSaveComment instead of being persisted immediately:

App/src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx

Lines 559 to 563 in cc90dd2

	if (shouldDebounceSaveComment) {
	debouncedSaveComment(newCommentConverted);
	} else {
	saveReportDraftComment(reportID, newCommentConverted);
	}

That debounced save uses DRAFT_SAVE_DEBOUNCE_TIME (1000 ms), and useDebounce calls debouncedFn.cancel() in its cleanup, so when the report screen unmounts during navigation the pending empty-draft save is cancelled and never reaches Onyx:

App/src/hooks/useDebounce.ts

Lines 30 to 36 in cc90dd2

	debouncedFnRef.current = debouncedFn;
	return () => {
	debouncedFn.cancel();
	};
	}, [func, wait, leading, maxWait, trailing]);

Timeline: typing the message debounce-saves it as the draft; pressing send schedules a debounced save of ''; if the user goes back within 1 s (a natural sequence when bouncing between Search and a chat, and even more likely on iOS where the send/clear hops through scheduleOnUI before onClear runs) the unmount cancels that pending empty save, leaving the old text as the persisted draft. Reopening the chat reads that stale draft back into the compose box.

What changes do you think we should make in order to solve the problem?

In onClear in src/pages/inbox/report/ReportActionCompose/ComposerWithSuggestions.tsx, clear the draft synchronously instead of debounced, by calling updateComment('') (omitting the shouldDebounceSaveComment argument) rather than updateComment('', true).

With the debounce flag dropped, updateComment takes the non-debounced branch and calls saveReportDraftComment(reportID, '') immediately, so the Onyx draft comment is set to empty the moment the message is sent. Because the write is no longer pending behind a 1 s timer, navigating away right after sending can no longer cancel it, and reopening the chat shows an empty compose box.

Debouncing is only useful for rapid keystrokes; sending is a single discrete action, so clearing the draft immediately on send has no downside and closes the race for all platforms.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/94118-clear-draft-on-send-sync?expand=1

What alternative solutions did you explore? (Optional)

Flushing the pending debounced save on unmount (or in the navigation blur handler) was considered, but that only narrows the race window and still relies on the unmount/flush ordering; saving the empty draft synchronously on send removes the race outright and is a smaller, more targeted change.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022068322912791692610