Skip to content

fix(app): treat benign 404 as recovery in processInProgressConversation (#9241)#9340

Merged
kodjima33 merged 1 commit into
mainfrom
issues-improver/9241-benign-404-inprogress-conversation
Jul 10, 2026
Merged

fix(app): treat benign 404 as recovery in processInProgressConversation (#9241)#9340
kodjima33 merged 1 commit into
mainfrom
issues-improver/9241-benign-404-inprogress-conversation

Conversation

@kodjima33

@kodjima33 kodjima33 commented Jul 9, 2026

Copy link
Copy Markdown
Collaborator

What

processInProgressConversation() in app/lib/backend/http/api/conversations.dart used to crash-report every non-200 response from POST /v1/conversations. A benign 404 now short-circuits to a debug log instead of a crash report; all other non-200 statuses still report a crash.

Why

The backend endpoint (backend/routers/conversations.py:162-165) raises 404 "Conversation in progress not found" when there is no in-progress conversation to process:

conversation = retrieve_in_progress_conversation(uid)
if not conversation:
    raise HTTPException(status_code=404, detail="Conversation in progress not found")
redis_db.remove_in_progress_conversation_id(uid)

This is exactly the race described in the issue:

Flutter crashes/reports when processInProgressConversation gets a benign 404 due to race with WS auto-finalize.

When the WS auto-finalize path finalizes the in-progress conversation and clears its Redis pointer first, a client-initiated create that races in finds nothing to process → 404. The conversation is already finalized, so there is nothing to recover — but the old code reported it as Exception('Failed to create conversation'), flooding crash reporting with noise that has no user-visible impact. The caller in capture_controller.dart already recovers gracefully on a null return (it removes the '0' processing placeholder).

Change

  • 404 → Logger.debug(...) and return null (benign, already-finalized).
  • Every other non-200 → unchanged crash report.
  • Extracted isBenignInProgressConversationCreateStatus(int) so the crash-vs-skip decision is covered by a hermetic regression test (the makeApiCall / crashReporter singletons aren't injectable — this mirrors the existing sync_response_handling_test.dart pattern of testing branching logic via a minimal abstraction).

Verified

  • Traced the exact backend 404 source and confirmed the caller already handles null without side effects.
  • Added app/test/unit/process_in_progress_conversation_test.dart asserting 404 is benign and 304/400/401/409/429/5xx still report.
  • Could not run app/test.sh in this environment — the build machine has no Flutter/Dart SDK. CI (app tests) will exercise the new unit test. The change is a single status-code branch with no visual surface.

Auto-generated from issue feedback by the mini issues-improver. Review before merge.

Review in cubic

POST /v1/conversations (process in-progress conversation) returns 404 when
there is no in-progress conversation to process. This happens as a benign
race: the WS auto-finalize path already consumed the in-progress conversation
and cleared its Redis pointer before this client-initiated create ran, so the
conversation is already finalized and there is nothing to recover.

Previously every non-200 response was crash-reported, so this race flooded
crash reporting with noise that has no user-visible impact (the caller already
recovers gracefully by removing the '0' processing placeholder on null). Now a
404 is logged and skipped; other non-200 responses still report a crash.

Extracted isBenignInProgressConversationCreateStatus for a hermetic regression
test, mirroring the codebase pattern of testing branching logic via a minimal
abstraction (the makeApiCall/crashReporter singletons aren't injectable).

fixes #9241
@kodjima33 kodjima33 merged commit eecc093 into main Jul 10, 2026
19 checks passed
@kodjima33 kodjima33 deleted the issues-improver/9241-benign-404-inprogress-conversation branch July 10, 2026 14:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant