• v1.4.23-ew-1 929fe7f562

    v1.4.23-ew-1 — EW Provider + OpenAI-conformant errors
    All checks were successful
    Docker Build / docker (push) Successful in 5m6s
    Docker Release / release (push) Successful in 4m56s
    Stable

    engel75 released this 2026-04-28 10:54:21 +02:00 | 6 commits to 1.4.23-ew since this release

    v1.4.23-ew-1

    Erstes Release des EW-flavored Bifrost-Forks. Setzt auf Upstream Bifrost v1.4.23 auf und ergänzt um den EW/SGLang-Provider, per-Key-API-Toggles sowie OpenAI-konforme Fehlerantworten auf den OpenAI-Compat-Routen.

    Highlights

    EW (SGLang) Provider

    • Neuer Provider ew für OpenAI-kompatible SGLang/EW-Instanzen
      • Per-Key-Konfiguration (ew_key_config.url, ew_key_config.model_name) — jede Key-Instanz routet auf einen eigenen Backend-Server
      • Round-Robin-Loadbalancing über mehrere SGLang-Backends
    • Streaming-Support für Chat, Text, Speech, Transcription
    • OpenAI-kompatible SpeechStream-Implementierung
    • SGLang-spezifischer Error-Parser (ParseSGLangError) — fängt sowohl die top-level ({"object":"error","message":...,"type":"BadRequestError","code":400}) als auch die streaming-wrapped ({"error":{...}}) Fehler-Shapes von SGLang ab und füllt den BifrostError mit der korrekten Message/Type

    Per-Key API Toggles

    Ein Operator kann pro EW-Key explizit steuern, welche APIs erlaubt sind:

    • ew_key_config.allowed_requests = null ⇒ alle APIs erlaubt (backwards compatible)
    • Explizite Whitelist für 16 EW-unterstützte APIs (Chat, Text, Responses, Embedding, Rerank, Speech, Transcription, Image-Gen/Edit/Variation, ListModels — jeweils inkl. Streaming-Varianten wo verfügbar)
    • Doppelte Durchsetzung:
      • Routing-Filter in selectKeyFromProviderForModel überspringt gesperrte Keys ⇒ Bifrost wählt automatisch einen anderen passenden Key
      • Defensiver Check in jeder EW-Provider-Methode liefert UnsupportedOperationError, falls der Key explizit per x-bf-key-id referenziert wird
    • UI-Toggles im Provider-Form (Workspace → Providers → EW Key)
    • Automatische DB-Migration add_ew_allowed_requests_column beim Start

    OpenAI-konforme Fehlerantworten

    Alle OpenAI-Compat-Routen liefern Fehler im OpenAI-Standardformat:

    {
      "is_bifrost_error": false,
      "status_code": 400,
      "error": {
        "message": "Requested token count exceeds the model's maximum context length of 196608 tokens. ...",
        "type": "invalid_request_error",
        "code": "context_length_exceeded",
        "param": "messages"
      },
      "extra_fields": {
        "provider": "ew",
        "model_requested": "minimax27",
        "request_type": "chat_completion_stream"
      }
    }
    
    • SGLang→OpenAI Type-Mapping: BadRequestError/BadRequest/DecodeErrorinvalid_request_error; InternalServerError/NotImplementedErrorapi_error; HTTP-Statuscodes (401/403/404/429) ⇒ authentication_error/permission_error/not_found_error/rate_limit_error.
    • Code-Heuristiken: „maximum context length" ⇒ context_length_exceeded; „no keys found" ⇒ model_not_found; pro Statuscode passende Defaults.
    • Bifrost-Diagnostik bleibt erhalten: is_bifrost_error, status_code und extra_fields an Top-Level (OpenAI-Clients ignorieren unbekannte Felder).
    • Vollständige Abdeckung: 45 ErrorConverter in integrations/openai.go, 2 in cursor.go, plus die nativen Pfade SendBifrostError/SendSSEError in handlers/utils.go.

    Bugfixes

    • Redaction-Lücke (framework/configstore/clientconfig.go): Beim Bauen der UI-Antwort wurden allowed_requests weggelassen, sodass beim Reload des Keys der Master-Switch auf „Allow All APIs" zurücksprang. ⇒ Behoben.
    • Native Streaming-Setup-Fehler: Wenn SGLang vor dem ersten SSE-Chunk einen 400 zurückgab, lief der Fehler durch SendBifrostError, das vorher den BifrostError 1:1 ausgab und die Integrations-ErrorConverter umging. ⇒ SendBifrostError/SendSSEError leiten jetzt durch ToOpenAIErrorEnvelope.

    Infrastruktur

    • Forgejo Actions Workflow (.forgejo/workflows/docker-release.yml): Baut Docker-Images automatisch auf v*-Tags und pusht nach forge.engelmann.me/engel75/bifrost:<tag>.
    • GitNexus MCP-Konfiguration für die Codebase.

    Wichtige Dateien

    Datei Bedeutung
    core/providers/ew/ (NEU) Kompletter EW-Provider inkl. errors.go (ParseSGLangError)
    core/schemas/account.go EWKeyConfig.AllowedRequests
    core/bifrost.go Routing-Filter für EW pro RequestType
    framework/configstore/tables/key.go + Migration DB-Persistenz
    framework/configstore/clientconfig.go Redaction-Bugfix
    transports/bifrost-http/integrations/utils.go OpenAIErrorEnvelope, ToOpenAIErrorEnvelope, SGLang→OpenAI Mapping-Tabelle
    transports/bifrost-http/integrations/openai.go + cursor.go ErrorConverter-Umstellung
    transports/bifrost-http/handlers/utils.go SendBifrostError/SendSSEError durch Envelope geleitet
    ui/lib/types/config.ts, schemas.ts TS-Typen + Zod-Schema für allowed_requests
    ui/app/workspace/providers/fragments/ewAllowedApisFields.tsx (NEU) EW-spezifische API-Toggle-Komponente
    ui/app/workspace/providers/fragments/apiKeysFormFragment.tsx Wiring des EW-Form-Bereichs

    Upgrade

    • Service neu starten — die DB-Migration läuft automatisch.
    • Bestehende EW-Keys behalten alle APIs erlaubt (Default allowed_requests = null).
    • Docker-Image: forge.engelmann.me/engel75/bifrost:v1.4.23-ew-1 (wird durch den Tag-Push gebaut).

    Bekannte Einschränkungen

    • Embedding-, Speech-, Transcription- (non-stream), Image-* haben keinen customErrorConverter-Slot in der OpenAI-Hilfsbibliothek. Dort werden Backend-Fehler weiterhin via ParseOpenAIError geparst — der Transport-Envelope normalisiert immerhin die JSON-Shape, aber bei tiefen Backend-Fehlern könnte die innere Message generisch sein („provider API error (status 400)") statt der originalen SGLang-Botschaft.
    Downloads