Errors and retry

Failures are data. A transport reports one as a BitAiErrorEvent carrying a BitAiError: a message safe to show, a machine-readable Code, a Kind, whether retrying could help (IsRetryable), how long to wait (RetryAfter) and the technical Detail. Components branch on that rather than on any provider's exception type.

Here the first request writes a few words, then sends a terminal BitAiErrorEvent: a rate limit (BitAiErrorKind.RateLimit) that is retryable after three seconds. The reply fails with the error on it, the session keeps it as LastError, and the error view shows the message, how long to wait (RetryAfter, until that time is up) and, since it is retryable, Try again - which calls BitAiChatSession.RetryAsync(): the failed reply is removed and the same user message is sent again, and this time the transport answers.

The session words two failures itself, with the same shape: a turn that runs out of BitAiChatSessionOptions.Timeout fails as a retryable Timeout, and a stopped turn keeps what it had written and is marked cancelled. An error sent with isTerminal: false does not end the reply: it adds a BitAiErrorPart and the stream goes on.

An exception that escapes the transport is translated into the same shape (unless BitAiChatSessionOptions.CatchTransportExceptions is turned off), so an unhandled failure still renders as a retryable error rather than tearing down the page. Whatever had already streamed is kept: losing a half-written answer to a network blip is worse than showing it with a retry button underneath.

• BitAiErrorView - what went wrong, the retry when it can help, and the detail behind a disclosure.
• BitAiChatMessage - the message that keeps its partial answer above the error.