React Native AI chat: streaming, retries and credit rules

Separate the message display from the operation state

The screen may be loading, streaming or offline while the server operation continues. Keep the operation state authoritative and let the interface explain uncertainty instead of treating every network error as a failed generation.

What should happen when the app loses connection?

1. The client keeps the operation ID associated with its pending message.
2. On reconnect, it asks the server for that operation’s status.
3. If completed, it retrieves the saved answer and existing usage receipt.
4. If still running, it resumes or polls using the supported transport; it does not create a second operation.
5. If definitively failed, it offers the agreed retry behavior. A new attempt and a duplicate delivery must remain distinguishable.

Whether you use SSE, a fetch stream or another transport depends on the native runtime, library and lifecycle requirements. Verify behavior in the intended build on both platforms. A streaming example in a desktop browser is insufficient evidence of mobile reconnect handling.

Stopping the screen does not necessarily stop provider cost

Define whether Stop hides the output, requests cancellation or ends an operation. An upstream provider may have already generated tokens by the time it receives cancellation. Your provider bill and the customer’s app credit are different accounting units.

Choose and disclose a customer policy for partial results, cancellation and server completion after disconnect. If you charge only for a completed saved answer, a cancelled or partial response should not silently appear as a completed debit. Reconcile races at the server: cancellation and completion must not both release and settle the same reservation.

Bind chat context to the right report and user

Authorize report access on the server before using it as chat context. Include the intended report version, a bounded message history and the current allowed memory snapshot. Keep provider credentials off the mobile client. Logs should avoid report bodies, health details and raw conversation text unless separately justified and disclosed.

If a user corrects a preference, use that new value for the next operation. Do not rewrite a previously delivered report as a side effect. See the editable memory guide for correction and deletion boundaries.

A failure checklist you can put in the launch scope

• Double-tap Send: only one intended operation and one settled debit.
• Disconnect mid-stream: reopening checks the existing operation first.
• Kill and relaunch the app: a completed answer is recoverable.
• Provider fails before completion: the visible balance follows the agreed failure policy.
• Cancel as completion arrives: exactly one final settlement decision.
• Expire the login while streaming: a different user cannot fetch the previous answer.
• Send with the last credit from two devices: the server enforces the reservation atomically.

The AppBento failure/retry illustration shows the sample balance 6 → 6 → 5. It is a preset browser example, not an implemented production recovery system. For an integration, agree which of the above cases must pass in the customer’s own environment.