18 releases 22 tags

RSS feed

• v1.5.11-ew-1 64cb0bdaf8

  Compare

  v1.5.11-ew-1: EW fork on bifrost v1.5.11 Stable

  engel75 released this 2026-06-08 16:31:48 +02:00 | 1 commits to 1.5.11-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.11.

  Tracking release — keine Feature‑Änderungen in der Fork gegenüber v1.5.10-ew-1. Zweiter Zero‑Conflict‑Port in Folge — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenüber v1.5.10 änderte)

  In der Fork: nichts. Upstream zwischen v1.5.10 und v1.5.11:

  • 12 substantielle Commits, davon nur 2 mit Overlap zu unserem Footprint (handlers/governance.go +11 Zeilen, governance_test.go) — beide Files, die unsere Fork nicht touched.
  • Keine neuen DB‑Migrationen in der Mitte unserer Ordering.
  • Keine API‑Drifts — die v1.5.10 Provider Interface Anpassungen (ConfigureDialer 2‑arg + Compaction stub) sind in der Fork bereits dauerhaft drin und propagieren automatisch.
  • Kein Go‑Bump — go.mod blieb auf 1.26.4 wie in v1.5.10.

  Alle 14 Cherry‑Picks liefen sauber durch, kein Follow‑up Commit nötig.

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.11-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.11 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.5.11-ew1 tracks this release. Frühere ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1, 1.5.10-ew1) bleiben verfügbar. Cherry-pick-Pfad für die nächste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.5.10-ew-1: trivialer Drop‑in. Keine fork‑seitige Schema‑Änderung und keine neue upstream Migration in der relevanten Reihenfolge. Symbol‑Set im Binary identisch (107 matches).
  • Von jeder älteren X.Y.Z-ew1 Version: in-place safe. Alle Migrationen sind idempotent über migrator_meta. Die akkumulierten upstream Migrationen aus v1.5.4 + v1.5.7 + v1.5.10 laufen automatisch.
  • Von upstream transports/v1.5.11 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • Alle Go test suites grün (handlers TestAuth, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean ohne Anpassung.
  • Symbol-Check: 107 matches im Binary (alle 5 Specs detektiert, identisch zu v1.5.10).
  • Version string in /app/main ist exakt v1.5.11-ew-1.

  See Spec 08 — Version Port Log für die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.5.10-ew-1 80c262535c

  Compare

  v1.5.10-ew-1: EW fork on bifrost v1.5.10 Stable

  engel75 released this 2026-06-08 09:30:09 +02:00 | 1 commits to 1.5.10-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.10 (commit b35e35da3, v1.5.9 übersprungen).

  Tracking release — keine Feature‑Änderungen in der Fork gegenüber v1.5.8-ew-1. Der Port war diesmal anspruchsvoller als die letzten (110 upstream Commits, 1 Konflikt + 2 API‑Follow‑ups) — siehe Spec 08 port log für Details.

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Port-Notes (was sich gegenüber v1.5.8 änderte)

  Im Code der Fork selbst: nichts. Aber upstream zwischen v1.5.8 und v1.5.10:

  • +8 neue DB-Migrationen (Model-Config Refactor: scope columns, customer budgets, FK constraints, governance migration). Standard-Resolution per Spec 06 — alle 8 vor unseren 2 EW-Migrationen einsortiert.
  • providerUtils.ConfigureDialer signatur change: zweiter bool Parameter für allowPrivateNetwork. EW Provider angepasst per Reference Pattern aus VLLM/OpenAI.
  • schemas.Provider interface: neue Compaction Methode. EW Provider liefert UnsupportedOperationError (SGLang hat keine native Compaction).
  • Go 1.26.3 → 1.26.4 in allen upstream go.mod. Dockerfile printf-String entsprechend gebumped (selbes Pattern wie beim v1.5.7 Port).

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.10-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.10 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health. Build-Stage nutzt Go 1.26.4 alpine image.

  Branches

  Branch 1.5.10-ew1 tracks this release. Frühere ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1, 1.5.8-ew1) bleiben verfügbar. Cherry-pick-Pfad für die nächste upstream Version: Spec 07 — Port Runbook.

  Upgrade notes

  • Von v1.5.8-ew-1: in-place safe. Die 8 neuen upstream Migrationen und unsere 2 EW Migrationen laufen alle idempotent über migrator_meta. Keine fork-seitige Schema-Änderung.
  • Von jeder älteren X.Y.Z-ew1 Version: in-place safe. Alle Migrationen sind idempotent.
  • Von upstream transports/v1.5.10 (kein EW bislang): beim ersten Boot werden die EW-Spalten in config_keys angelegt. Existierende Keys bleiben unangetastet.

  Verification

  • All Go test suites grün (handlers TestAuth, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean nach Go 1.26.4 bump.
  • Symbol-Check: 107 matches im Binary (alle 5 Specs detektiert).
  • Version string in /app/main ist exakt v1.5.10-ew-1.

  See Spec 08 — Version Port Log für die volle per-Version Historie.

  Downloads

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    1 download
• v1.5.8-ew-1 ddb8bfff03

  Compare

  v1.5.8-ew-1: EW fork on bifrost v1.5.8 Stable

  engel75 released this 2026-06-04 15:01:12 +02:00 | 0 commits to 1.5.8-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.8 (commit 7c5ab44e2).

  Tracking release with no functional changes vs. v1.5.7-ew-1 — the new upstream v1.5.8 was a small delta (14 substantive commits) and the EW fork cherry-picked cleanly with zero conflicts (see Spec 08 port log).

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.8-ew-1
  

  Identical runtime semantics to upstream transports/v1.5.8 plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root, healthcheck on /health.

  Branches

  Branch 1.5.8-ew1 tracks this release. Earlier ew1 releases (1.5.3-ew1, 1.5.4-ew1, 1.5.7-ew1) remain available. Cherry-pick path for the next upstream version is documented in Spec 07 — Port Runbook.

  Upgrade notes

  • From v1.5.7-ew-1: trivial — no DB schema change in our fork, only upstream v1.5.7 → v1.5.8 changes (5 already-applied upstream migrations from v1.5.7 + no new EW migration). Drop-in container replacement.
  • From any earlier X.Y.Z-ew1 release: in-place safe. The two EW DB migrations (add_ew_key_config_columns, add_ew_allowed_requests_column) are idempotent via migrator_meta. Any intermediate upstream migrations apply automatically.
  • From upstream transports/v1.5.8 (no EW yet): on first boot the EW migrations create the new EW columns on config_keys. Existing keys are unaffected.

  Verification

  • Zero merge conflicts on the v1.5.7 → v1.5.8 cherry-pick.
  • All Go test suites green (handlers, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean.
  • Symbol check confirms all 5 fork features baked into the binary (106 matches).
  • Version string in /app/main is exactly v1.5.8-ew-1.

  See Spec 08 — Version Port Log for the full per-version history.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    0 downloads
• v1.5.7-ew-1 db36805c5a

  Compare

  v1.5.7-ew-1: EW fork on bifrost v1.5.7 Stable

  engel75 released this 2026-06-04 13:14:35 +02:00 | 0 commits to 1.5.7-ew1 since this release

  EW fork release based on upstream bifrost transports/v1.5.7 (commit b4b95ff8a).

  Contents

  Spec	Feature
  01	EW (SGLang/OpenAI-compatible) provider — chat/text completion (+ stream), embeddings, responses, speech (+ stream), transcription (+ stream), rerank, image gen/edit/variation, list_models with owned_by="everyware" override
  02	Per-key API toggles (EWKeyConfig.AllowedRequests) — restrict an EW key to a subset of operations
  03	OpenAI-conformant error envelope on /v1/... and /cursor/... routes + SGLang-aware error parser
  04	WhitelistedRoutes config also bypasses auth for inference routes (e.g. /v1/models) and the governance VK-required gate
  05	Dockerfile builds with all local plugins via go.work, Forgejo Actions workflows for branch + tag builds

  Container image

  The Docker Release workflow publishes:

  forge.engelmann.me/engel75/bifrost:v1.5.7-ew-1
  

  docker run against this image is functionally identical to the upstream transports/v1.5.7 binary, plus all of the above EW features. Built statically (CGO + sqlite_static), runs as non-root user, healthcheck on /health.

  Branches

  Branch 1.5.7-ew1 tracks this release. Earlier ew1 releases (1.5.3-ew1, 1.5.4-ew1) remain available; cherry-pick path documented in Spec 07 — Port Runbook.

  Upgrade notes

  • From any prior X.Y.Z-ew1 release: in-place safe. The two EW DB migrations (add_ew_key_config_columns, add_ew_allowed_requests_column) are idempotent via migrator_meta. Upstream v1.5.4 → v1.5.7 added 4 new VK migrations (add_per_user_headers_*, add_mcp_client_tls_config, add_additional_attributes_to_pricing, drop_azure_api_version) — all also idempotent.
  • From upstream transports/v1.5.7 (no ew yet): on first boot the EW migrations create two new columns on config_keys (ew_url, ew_model_name, ew_allowed_requests_json). Existing keys are unaffected.

  Verification

  • All Go test suites green (handlers, integrations, core/providers/ew, framework/configstore -short).
  • docker build clean (build cache fresh + warm), image runs.
  • Symbol check confirms all 5 fork features baked into the binary.
  • Version string in /app/main is exactly v1.5.7-ew-1.

  See Spec 08 — Version Port Log for the conflict resolutions encountered during the v1.5.4 → v1.5.7 port.

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.4.23-ew-4 8b6f8e1495

  Compare

  v1.4.23-ew-4 — fix Dockerfile to ship local plugin code Stable

  engel75 released this 2026-04-29 09:38:58 +02:00 | 0 commits to 1.4.23-ew since this release

  v1.4.23-ew-4

  Patch-Release auf v1.4.23-ew-3.

  Bugfix: WhitelistedRoutes-Bypass fürs Governance-Plugin landete nie im Image

  In v1.4.23-ew-3 haben wir den VK-Pflicht-Bypass im Governance-Plugin (Commit 55515ff37) committet, aber das gebaute Docker-Image hat den Bypass NIE ausgeliefert.

  Ursache: Der Dockerfile-Build erstellt einen go.work mit nur core/ und framework/. Alle Plugins — auch governance — werden über transports/go.mod aus dem Module-Cache (Upstream-Versionen, z. B. governance v1.4.39) gezogen. Lokale Plugin-Änderungen waren also unsichtbar für den Build.

  Folge: /v1/models lieferte trotz WhitelistedRoutes-Eintrag weiter 401 virtual key is required — die VK-Pflicht im Plugin lief gegen die alte Upstream-Version.

  Fix: Alle 8 lokalen Plugins (governance, litellmcompat, logging, maxim, mocker, otel, semanticcache, telemetry) werden ins Build-Image kopiert und in den Workspace aufgenommen. Damit baut go build jeden Plugin aus lokalem Source statt aus der pinned Module-Cache-Version.

  Was geändert wurde

  transports/Dockerfile:

  • COPY plugins/ /plugins/ ergänzt.
  • Workspace-Generation um alle 8 Plugin-Pfade erweitert:

    use (
        .
        /core
        /framework
        /plugins/governance
        /plugins/litellmcompat
        /plugins/logging
        /plugins/maxim
        /plugins/mocker
        /plugins/otel
        /plugins/semanticcache
        /plugins/telemetry
    )
    

  Warum betraf das nicht alle Änderungen?

  Frühere Patch-Releases haben funktioniert, weil ihre Änderungen in core/, framework/ oder transports/ lagen — diese drei Module sind seit jeher Teil der Workspace. Erst 55515ff37 (Bypass im Governance-Plugin) musste über plugins/governance/ deployed werden — und genau da hatte der Build die Lücke.

  Upgrade

  Nach diesem Image-Push: einmal pullen + neu starten. Die UI-Konfiguration bleibt unverändert (Whitelist-Eintrag z. B. /v1/models).

  Vollständiger Changelog

  v1.4.23-ew-3...v1.4.23-ew-4

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    0 downloads
• v1.4.23-ew-3 4bd6a4d97e

  Compare

  v1.4.23-ew-3 — public /v1/models via WhitelistedRoutes Stable

  engel75 released this 2026-04-28 18:39:16 +02:00 | 1 commits to 1.4.23-ew since this release

  v1.4.23-ew-3

  Patch-Release auf v1.4.23-ew-2.

  Highlight: Inference-Routen über WhitelistedRoutes öffentlich machen

  Das bestehende Setting Workspace → Config → Security → "Whitelisted Routes" greift jetzt auch für Inference-Endpunkte (z. B. /v1/models). Vorher griff es nur für /api/...-Dashboard-Routen.

  Anwendungsfall:

  1. „Password protect the dashboard" aktiviert, „Enforce virtual keys on inference" aktiviert.
  2. /v1/models (oder /v1/models*, /v1/*) unter „Whitelisted Routes" eintragen.
  3. curl http://bifrost/v1/models ohne Authorization-Header und ohne x-bf-vk-Virtual-Key liefert die Modellliste.

  Anonyme Aufrufe sehen die ungefilterte Modellliste — Virtual-Key-basiertes Filtering kann ohne Virtual Key naturgemäß nicht greifen.

  Was passiert ist

  Das Setting WhitelistedRoutes lebte schon, aber die Enforcement war auf zwei Schichten unvollständig:

  1. AuthMiddleware (Basic-Auth/Session-Token) prüfte die Whitelist nur in APIMiddleware (für /api/...), nicht in InferenceMiddleware (für /v1/...).
  2. Selbst wenn die AuthMiddleware durchließ, gab das Governance-Plugin unabhängig „virtual key is required" zurück, sobald „Enforce auth on inference" aktiv war.

  Beide Schichten respektieren jetzt die Whitelist.

  Was geändert wurde

  feat(auth): allow inference routes in WhitelistedRoutes config

  • transports/bifrost-http/handlers/middlewares.go: Match-Logik (exakt + *-Suffix-Wildcard) in isUserWhitelisted extrahiert. InferenceMiddleware ruft den Helper jetzt zusätzlich zu DisableAuthOnInference. APIMiddleware-Verhalten unverändert.
  • UI: Hilfetext und Placeholder im Security-Tab erwähnen Inference-Routen.

  fix(auth): propagate WhitelistedRoutes bypass into governance plugin

  • Neue Context-Konstante schemas.BifrostContextKeyAuthRouteWhitelisted in core/schemas/bifrost.go.
  • AuthMiddleware setzt das Flag, wenn die URL gegen die User-Whitelist matcht.
  • plugins/governance/main.go:evaluateGovernanceRequest checkt das Flag ganz vorne und gibt direkt DecisionAllow zurück — vor dem VK-Pflicht-Gate.

  fix(auth): strip query string before whitelist match

  • isUserWhitelisted strippt jetzt ?… vom URL, bevor sie matcht. Damit greift ein exakter Eintrag /v1/models auch bei Aufrufen wie /v1/models?provider=openai.

  Geänderte Dateien

  • core/schemas/bifrost.go — neue Context-Konstante.
  • transports/bifrost-http/handlers/middlewares.go — Helper, Inference-Whitelist, Query-String-Strip.
  • transports/bifrost-http/handlers/middlewares_test.go — Regression-Tests (5 Fälle inkl. Query-String).
  • plugins/governance/main.go — Bypass im Plugin.
  • ui/app/workspace/config/views/securityView.tsx — Hinweistext + Placeholder.

  Upgrade

  • Service neu starten, Docker-Image: forge.engelmann.me/engel75/bifrost:v1.4.23-ew-3 (wird durch Tag-Push gebaut).
  • Bestehende Whitelist-Einträge werden automatisch auch für Inference-Routen wirksam — keine Migration nötig.

  Vollständiger Changelog

  v1.4.23-ew-2...v1.4.23-ew-3

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.4.23-ew-2 43b2fc60f2

  Compare

  v1.4.23-ew-2 — owned_by override + Docker version fix Stable

  engel75 released this 2026-04-28 13:08:24 +02:00 | 4 commits to 1.4.23-ew since this release

  v1.4.23-ew-2

  Patch-Release auf v1.4.23-ew-1.

  Neuerungen

  EW-Provider: owned_by Override (feat)

  Die /v1/models-Antwort gibt für jedes Modell des EW-Providers jetzt owned_by: "everyware" zurück, unabhängig davon, was die SGLang-Backends melden. SGLang reicht typischerweise den ursprünglichen Hugging-Face-Owner durch (z. B. Qwen, meta-llama); für EW-Deployments ist der kanonische Eigentümer aber der Operator, nicht der Modell-Autor.

  Implementierung: Override in listModelsByKey direkt nach dem geteilten openai.ListModelsByKey-Call. Konstante EWModelOwner = "everyware" in core/providers/ew/ew.go. Regression-Test in list_models_test.go ergänzt.

  Bugfixes

  Docker-Build: doppeltes v in der Binary-VERSION (fix)

  Der Forgejo-Actions-Workflow docker-release.yml reicht den Git-Tag (z. B. v1.4.23-ew-1) als --build-arg VERSION=… weiter, das transports/Dockerfile setzte aber zusätzlich nochmal ein v davor (-X main.Version=v${VERSION}). Folge: Die Binary meldete ihre Version als vv1.4.23-ew-1.

  Behoben durch:

  • Default-ARG VERSION=v1.4.23-ew (mit v-Prefix).
  • ldflag jetzt -X main.Version=${VERSION} (kein zusätzliches v mehr).

  Makefile, Dockerfile.local und die GitHub-Action-Skripte lesen VERSION aus transports/version (Wert ohne v-Prefix) und behalten ihre v${VERSION}-Form bei — dort ist das v korrekt.

  Geänderte Dateien

  • core/providers/ew/ew.go — EWModelOwner-Konstante + Override-Loop in listModelsByKey.
  • core/providers/ew/list_models_test.go — Regression-Test für owned_by == "everyware".
  • transports/Dockerfile — doppeltes v entfernt.

  Upgrade

  Service neu starten und Docker-Image forge.engelmann.me/engel75/bifrost:v1.4.23-ew-2 ziehen (wird durch den Tag-Push gebaut).

  Vollständiger Changelog

  v1.4.23-ew-1...v1.4.23-ew-2

  Downloads

  • Source code (ZIP)
    1 download
  • Source code (TAR.GZ)
    1 download
• v1.4.23-ew-1 929fe7f562

  Compare

  v1.4.23-ew-1 — EW Provider + OpenAI-conformant errors 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/DecodeError ⇒ invalid_request_error; InternalServerError/NotImplementedError ⇒ api_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

  • Source code (ZIP)
    0 downloads
  • Source code (TAR.GZ)
    0 downloads