fix: show budget-limit message on 429 instead of generic error

[biswajitpanda-dev]

fix: show budget-limit message on 429 instead of generic error

Problem

When a conversation exceeds its context_max_tokens budget, the backend correctly returns HTTP 429. However, the widget rendered the generic "Something went wrong. Please try again." message — implying a transient failure and prompting the user to retry, even though every retry will also 429.

Root Cause

submit() in AgentChatApp.tsx caught all stream errors and attempted a non-streaming fallback (sendToAgent), which also 429s. The inner catch then unconditionally rendered the generic error string, with no inspection of the HTTP status.

Changes

AgentChatApp.tsx

• Added error?: boolean field to MessageEntry type.
• In submit(), detect AgentChatHttpError.status === 429 before attempting the non-streaming fallback. When matched, immediately render a clear non-retriable message ("This conversation has reached its context limit. Please start a new chat to continue.") and skip the fallback entirely.
• Also cleaned up the redundant ternary in the generic error fallback.

shadcnAiElements.tsx

• Added error?: boolean prop to Message, which conditionally applies the msg-error CSS class.

styles.ts

• Added .msg.ai.msg-error rule — red-tinted text, background, and border — to visually distinguish permanent error messages from normal AI responses.

tests/agent_manager/test_api.py

• Added test_send_returns_429_when_token_budget_exceeded
• Added test_stream_returns_429_when_token_budget_exceeded

Testing

Both new tests use a ConversationService configured with max_tokens=1, exhaust the budget with a first message, then assert the second returns 429 with "budget" in the detail — covering both the /messages and /messages/stream endpoints.

[AmitAvital1]

Hi! Can you please star the project so i can assign to you the issue? Tnx

[AmitAvital1]

Can you fix the verifier?

[biswajitpanda-dev]

Hi @AmitAvital1 , I just starred the project, please assign the issue to me.

[AmitAvital1]

FE layer should be stateless as much as can, who handling the error should be BE and FE only parsing it or maybe detailed it with human read able string. GENERIC ERROR should be only if we got error not known but here we should upstream dedicated error, and check by 429 is good, but not enough. maybe we can do a little infra that we hold message on body and and FE parse just unmarshall and parse it