fix(app): hide pending-delete conversations from refresh result

[mdmohsin7]

Summary

Users reported that deleting a conversation in the app and then pulling-to-refresh "a few seconds later" makes the conversation reappear, as if the delete failed.

The backend isn't failing. Verified via GCP HTTPS LB access logs: 331/331 DELETE /v1/conversations/* requests in the last 24h returned 204 — every delete that reaches the server succeeds.

The actual bug is a client-side race: swipe-to-delete in deleteConversationLocally removes the conversation from the local list and schedules a Future.delayed(3s, sendDelete) for the undo window. A pull-to-refresh inside that 3-second window re-fetches the server list, which still has the conversation (DELETE hasn't fired yet), and fetchConversations() overwrites conversations with the fresh server list without filtering anything pending-delete — so the just-deleted conversation reappears. After the 3s timer fires, the DELETE actually goes out and succeeds, but the user has already seen "delete didn't work".

Fix

Add a tiny _filterPendingDeletes() helper and apply it to every list assignment that comes from the server:

• Fresh fetch result (fetchConversations).
• Paginated fetch result (getMoreConversationsFromServer).
• Cached fallback when the fetch fails or returns empty.

The conversation stays hidden until either (a) the undo timer fires and the server DELETE lands, at which point it disappears for real, or (b) the user taps Undo, at which point undoDeletedConversation removes it from memoriesToDelete and the next refresh shows it normally.

12 lines changed (1 helper + 4 call sites), no public API change, no backend change.

Test plan

• Swipe-to-delete a conversation → pull-to-refresh within 3s → conversation does not reappear.
• Swipe-to-delete → wait 5s → pull-to-refresh → conversation stays gone (DELETE has fired, server confirms 204).
• Swipe-to-delete → tap Undo within 3s → pull-to-refresh → conversation reappears (correct).
• Detail-page confirm-delete → pull-to-refresh quickly → conversation does not flicker back. (Detail path goes via fire-and-forget too, but with no undo timer; this PR doesn't change that path, but it's a much narrower race.)
• Conversation list still renders correctly on cold start when no deletes are pending.

🤖 Generated with Claude Code

[cubic-dev-ai]

1 issue found across 1 file

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="app/lib/providers/conversation_provider.dart">

<violation number="1" location="app/lib/providers/conversation_provider.dart:773">
P2: Pending-delete filtering stops too early because IDs are cleared before DELETE completion. On slow network, pull-to-refresh can still reintroduce a just-deleted conversation.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P2: Pending-delete filtering stops too early because IDs are cleared before DELETE completion. On slow network, pull-to-refresh can still reintroduce a just-deleted conversation.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At app/lib/providers/conversation_provider.dart, line 773:

<comment>Pending-delete filtering stops too early because IDs are cleared before DELETE completion. On slow network, pull-to-refresh can still reintroduce a just-deleted conversation.</comment>

<file context>
@@ -761,6 +766,14 @@ class ConversationProvider extends ChangeNotifier {
+  // or in-flight HTTP). Without this, a pull-to-refresh during that window
+  // re-surfaces the just-deleted conversation, which users read as "delete didn't work".
+  List<ServerConversation> _filterPendingDeletes(List<ServerConversation> items) {
+    if (memoriesToDelete.isEmpty) return items;
+    return items.where((c) => !memoriesToDelete.containsKey(c.id)).toList();
+  }
</file context>

[kodjima33]

mobile bug fix conf 4/5: filter pending-delete conversations from refresh/load-more so they don't re-surface during the 3s undo window