fix(craft): hide session limit

[rohoswagger]

Description

hide session limit

How Has This Been Tested?

locally

Additional Options

• [Required] I have considered whether this PR needs to be cherry-picked to the latest beta branch.
• [Optional] Override Linear Check

---

Summary by cubic

Shows an upgrade modal when users hit Craft message limits and makes paid limits configurable with per-user overrides. Also hides the sessions count when limit is unlimited (limit=0).

• New Features

  • Added UpgradePlanModal that opens on 429 rate-limit errors or when a limited user tries to send a message; usage limits refresh after each send.
  • Implemented backend rate limit config: free users get 5 total messages; paid users get a weekly limit via CRAFT_PAID_USER_RATE_LIMIT (default 25); per-user overrides via CRAFT_USER_RATE_LIMIT_OVERRIDES (JSON), treated as weekly.
  • Added RateLimitError handling in the client and a SessionErrorCode to surface the upsell flow cleanly.

• Migration

  • Optional env vars: set CRAFT_PAID_USER_RATE_LIMIT and CRAFT_USER_RATE_LIMIT_OVERRIDES (JSON map of email -> limit).
  • Ensure NEXT_PUBLIC_CLOUD_ENABLED is true to fetch and display usage limits.

^{Written for commit 594a595. Summary will update on new commits.}

[greptile-apps]

Greptile Overview

Greptile Summary

This PR implements a comprehensive upgrade upsell flow for Onyx Craft when users hit their free message limits. The changes span both backend rate limiting configuration and frontend UI for the upgrade experience.

Key Changes:

• Made rate limits configurable via environment variables (CRAFT_PAID_USER_RATE_LIMIT, CRAFT_USER_RATE_LIMIT_OVERRIDES)
• Updated default paid user limit from 50 to 25 messages per week
• Added per-user rate limit override capability for special cases
• Fixed session count display to hide when limit is 0 (self-hosted/unlimited mode)
• Implemented UpgradePlanModal to encourage upgrades when limits are reached
• Added proper rate limit error handling with RateLimitError class and SessionErrorCode.RATE_LIMIT_EXCEEDED
• Integrated limit checks before message sending and automatic limit refresh after sends

Issues Found:

• UpgradePlanModal uses raw HTML buttons instead of the Button component from @/refresh-components/buttons/Button (violates web standards)
• Modal uses dark: Tailwind modifiers which bypass the custom color system in colors.css (violates web standards)
• Debugging console.warn statement should be removed from production code in useBuildStreaming.ts

Confidence Score: 4/5

• Safe to merge after addressing style issues - no logical errors or breaking changes
• The implementation is functionally solid with proper error handling and limit checking. Backend changes are well-structured with good defaults. The main issues are frontend style violations (raw buttons, dark mode modifiers) and a debug log that should be removed. These are non-critical but should be fixed to maintain codebase standards.
• web/src/app/craft/components/UpgradePlanModal.tsx needs style updates to use Button component and remove dark: modifiers

Important Files Changed

Filename	Overview
backend/onyx/server/features/build/api/rate_limit.py	Added configurable rate limits with per-user overrides and updated defaults from 50 to 25 for paid users
web/src/app/craft/components/ChatPanel.tsx	Integrated usage limits checking and upgrade modal, with proper limit refresh after message sends
web/src/app/craft/components/UpgradePlanModal.tsx	New upgrade modal component with web standards violations (raw buttons, dark mode modifiers)
web/src/app/craft/hooks/useBuildStreaming.ts	Added rate limit error handling with debugging log that should be removed

Sequence Diagram

sequenceDiagram
    participant User
    participant ChatPanel
    participant UsageLimits as useUsageLimits Hook
    participant API as Backend API
    participant StreamingHook as useBuildStreaming
    participant Modal as UpgradePlanModal

    User->>ChatPanel: Load Craft page
    ChatPanel->>UsageLimits: Fetch usage limits
    UsageLimits->>API: GET /api/build/rate-limit
    API-->>UsageLimits: {isLimited, messagesUsed, limit, limitType}
    UsageLimits-->>ChatPanel: Return limits

    alt User at limit (isLimited=true)
        User->>ChatPanel: Try to send message
        ChatPanel->>ChatPanel: Check limits?.isLimited
        ChatPanel->>Modal: Show upgrade modal
        Modal-->>User: Display "reached limit" message
        User->>Modal: Click "Upgrade"
        Modal->>User: Navigate to /admin/billing
    else User under limit (isLimited=false)
        User->>ChatPanel: Send message
        ChatPanel->>StreamingHook: streamMessage(sessionId, message)
        StreamingHook->>API: POST /api/build/sessions/{id}/message
        
        alt Rate limit hit during stream
            API-->>StreamingHook: 429 Rate Limit Error
            StreamingHook->>StreamingHook: Catch RateLimitError
            StreamingHook->>ChatPanel: Update session.error = RATE_LIMIT_EXCEEDED
            ChatPanel->>ChatPanel: Detect error via useEffect
            ChatPanel->>Modal: Show upgrade modal
            ChatPanel->>UsageLimits: refreshLimits()
        else Message sent successfully
            API-->>StreamingHook: Stream response packets
            StreamingHook-->>ChatPanel: Update session with messages
            ChatPanel->>UsageLimits: refreshLimits()
            UsageLimits->>API: Fetch updated limits
        end
    end

Loading

[cubic-dev-ai]

No issues found across 9 files