lmarena-core: SSE unit tests, deterministic non-JSON handling, and total retry time cap

[Copilot]

Adds test coverage and two behavioral improvements to the LMArena provider introduced in PR #15.

SSE parser extraction + tests (parseSSEStream)

Inline SSE buffer logic extracted from generateContentStream into an exported parseSSEStream(stream) generator, making it directly testable without needing to mock the full axios/HTTP stack.

9 unit tests covering:

• JSON payload split across chunk boundaries (buffer accumulation)
• Stream ending without trailing \n (flush path)
• [DONE] sentinel — both in-loop and flush path
• Non-JSON data: lines (keep-alives, pings) skipped deterministically at debug level, never throwing

// now testable in isolation
import { parseSSEStream } from '../src/providers/lmarena/lmarena-core.js';

const chunks = makeStream('data: {"id":1}\n', 'data: [DONE]\n', 'data: {"id":2}\n');
expect(await collect(parseSSEStream(chunks))).toEqual([{ id: 1 }]); // stops at [DONE]

Total retry time cap (REQUEST_MAX_RETRY_TIME_MS)

_callApi now tracks wall-clock elapsed time across recursive retries and stops retrying once elapsed >= REQUEST_MAX_RETRY_TIME_MS, regardless of how many attempts remain under REQUEST_MAX_RETRIES. The last error is always surfaced.

• New config key: REQUEST_MAX_RETRY_TIME_MS (default 30000 ms)
• retryStartTime threaded through recursive calls via a 4th parameter (backward compatible, defaults null → Date.now() on first call)
• 4 unit tests using Jest fake timers: cap governs over count, count governs when cap is large, zero cap = no retries, 429 still sets shouldSwitchCredential

Config example

configs/config.json.example updated to show REQUEST_MAX_RETRY_TIME_MS: 30000 alongside the existing retry settings.

---

Note: The two retry branches in _callApi (503/network-error path and general 5xx path) have pre-existing structural duplication not introduced here; worth a follow-up refactor.

Original prompt

Repo: crazyrob425/BlacklistedAIProxy

Target PR: #15 (branch copilot/research-combining-features -> main).

Apply the following improvements to the PR (update the existing PR branch):

1. Add unit tests covering SSE parsing behavior in src/providers/lmarena/lmarena-core.js:

   • JSON split across chunks
   • stream ending without a trailing newline (flush behavior)
   • [DONE] handling
   • include a case where a data: line is not JSON and should be skipped deterministically

2. Make handling of non-JSON data: lines deterministic/documented:

   • Keep current behavior (skip non-JSON) but ensure it is explicit and test-backed.
   • If appropriate, adjust logging to avoid overly noisy logs (debug-level is OK).

3. Add a cap on total retry time (not just retry count) for _callApi in LMArenaApiService:

   • Respect existing REQUEST_MAX_RETRIES and REQUEST_BASE_DELAY settings.
   • Introduce a new config option for max total retry time (e.g., REQUEST_MAX_RETRY_TIME_MS), with a sane default.
   • Ensure retries stop once the cap is exceeded and the last error is surfaced.
   • Add unit tests for retry cap behavior using mocks/fake timers.

Constraints:

• Keep changes minimal and consistent with existing code style.
• Ensure npm test / existing test runner passes.
• Update any docs/config examples if they exist in-repo.

Notes:

• The PR already added SSE buffer flush and removed invalid http.Agent timeout; do not regress those.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Explain these changes.

Assistant: This PR change adds a new model provider identifier to your shared constants.

What changed

In src/utils/constants.js, inside the MODEL_PROVIDER enum/object, you added:

• LMARENA_BRIDGE: 'lmarena-bridge'

So the object now recognizes a new provider key (LMARENA_BRIDGE) that maps to the provider slug/string ('lmarena-bridge').

What it means in practice

• Anywhere in the codebase that does provider selection/routing like:
  • MODEL_PROVIDER.* comparisons
  • config parsing / env var mapping
  • switch/case on provider values
  • UI dropdowns listing providers
  • telemetry/logging keyed by provider
    …can now reference MODEL_PROVIDER.LMARENA_BRIDGE as a first-class option.

What it doesn’t do (yet)

This does not implement the provider—no wiring, no handler, no adapter, no routing logic—unless other files in the PR add that. This single-line change only makes the constant available so other code can select "lmarena-bridge" without hardcoding the string.

User: explain it n alayeman non programmer terms

Assistant: This PR basically adds a new “plug-in” option to your app so it can talk to a helper service called LMArenaBridge, which then gives access to a bunch of different AI models through one OpenAI-style doorway.

In normal-person terms:

What this update does

1) Adds a new AI “source” you can choose: LMArena Bridge

Before: your proxy knew about providers like OpenAI/Codex, Forward API, Grok custom, etc.
Now: it also knows about “LMArena Bridge” as another option in the list.

Think of it like adding a new streaming service to a smart TV menu.

---

2) Adds a list of model names that belong to that new source

It adds a catalog of model options under that provider, like:

• “auto pick”
• GPT models
• Claude models
• Gemini models
• Grok models
• Deepseek, Llama, Mistral, etc.

So the system can show/validate “these are the models you can request when you’re using this provider”.

---

3) Adds the actual connector code that forwards requests to the bridge

A new file (lmarena-core.js) acts like a translator + courier:

• It sends your chat request to the LMArenaBridge service at a URL you configure (like http://localhost:8000)
• It can optionally include an API key (if your bridge is locked down)
• It checks if the bridge is alive (/health)
• It supports streaming replies (the “answer comes in chunks live” style)
• If the network hiccups, it retries automatically

So: your proxy doesn’t directly “become” those models—it hands the job off to the bridge.

---

4) Says “this provider speaks OpenAI-style”

Another small file (lmarena-strategy.js) basically tells your routing system:

“Treat LMArena like OpenAI protocol, because it looks the same from the outside.”

Meaning it can reuse the same “OpenAI-shaped” request/response flow.

---

What you (as the operator) would need to do

To actually use it, you’d run that LMArenaBridge side service somewhere and set config values like:

• LMARENA_BRIDGE_URL (required)
• LMARENA_BRIDGE_API_KEY (optional)
• LMARENA_MODEL_OVERRIDE (optional)

No bridge running = this provider won’t work.

---

One-liner summary

You added a new “middleman” provider that lets your proxy access a big buffet of AI models via a single OpenAI-compati...

This pull request was created from Copilot chat.

[crazyrob425]

@copilot translate all text to us english