fix(qwen-web): migrate to v2 chat API with full cookie-jar replay (#3288)

[diegosouzapw]

What

Migrates the Qwen Web (Tongyi) provider (qwen-web) from the retired v1 chat API to the current v2 flow, fixing #3288 and the follow-up in discussion #2768.

Why

The legacy endpoint https://chat.qwen.ai/api/chat/completions was retired upstream. It now returns 504 HTML from Alibaba's gateway (alibaba-ga) for every request — verified with no credentials at all — so no amount of token refreshing could ever work. The reporter (@r3c0nshade) tried fresh tokens from multiple accounts and Chrome profiles; all failed because the endpoint itself is dead.

Probe evidence (2026-06-12, plain HTTP):

Request	Result
POST /api/chat/completions (old executor)	504 text/html, gateway alibaba-ga, for every request
POST /api/v2/chat/completions	200 text/html — Aliyun WAF JS challenge
POST /api/v2/chats/new	200 text/html — same WAF challenge
GET /api/models	200 JSON — catalog rotated to qwen3.7-plus/max, qwen3.6-plus

Changes

• open-sse/executors/qwen-web.ts — rewritten to the two-step v2 flow: POST /api/v2/chats/new → POST /api/v2/chat/completions?chat_id=. Parses the phase-based SSE (think/thinking_summary → reasoning_content, answer/null → content) into OpenAI chunks for both streaming and non-streaming. Maps the WAF/expired HTML page to a clear, actionable auth error (401) instead of surfacing raw 504 HTML.
• Full cookie-jar replay — the v2 endpoints sit behind Alibaba's "baxia" WAF, which needs the full browser cookie jar (cna, ssxmod_itna, ssxmod_itna2, token, ...), not just a Bearer token. New buildQwenCookieHeader / extractQwenToken helpers in webCookieAuth.ts, mirroring how grok-web replays its anti-bot cookies. Also sends the bx-v / bx-umidtoken / source: web headers.
• webSessionCredentials.ts — qwen-web becomes a full-cookie provider (kind: "cookie", acceptsFullCookieHeader: true) with an updated placeholder instructing users to paste the full Cookie header.
• tokenExtractionConfig.ts — browser login now captures the WAF cookies (cna, ssxmod_itna, ssxmod_itna2) alongside the token.
• Catalog refresh — providerRegistry.ts + freeModelCatalog.data.ts updated to the current upstream ids (qwen3.7-max, qwen3.7-plus, qwen3.6-plus), no longer discontinued. Legacy ids (qwen-plus, qwen3-max, ...) still resolve via the executor's MODEL_ALIASES.

Tests (Rule #18 — TDD)

The fix is grounded in two independent reference implementations (gpt4free Qwen.py, Chat2API qwen-ai.ts) and pinned by 17 new unit tests:

• executor-qwen-web.test.ts (11): v2 two-step flow + payload shape, full cookie-jar + bearer replay on every call, anti-bot headers, think→reasoning mapping, WAF-504-HTML → clean auth error, streaming chunk transform, bare-token back-compat, legacy-id alias mapping, registry/catalog assertions.
• web-cookie-auth.test.ts (6): buildQwenCookieHeader / extractQwenToken.

Gates: lint 0 errors, typecheck:core clean, check:any-budget:t11 pass, check:cycles pass, 110 related unit tests green. The two pre-existing vitest failures (free-pool-tab, AutoComboCatalog) and the docs-sync version mismatch are unrelated to this change (confirmed via clean-tree baseline-compare).

Residual validation note

Unit tests validate the request shape, SSE parsing, and error handling deterministically — the established validation path for OmniRoute's web-cookie executors. The one thing CI cannot exercise is whether Alibaba's live WAF accepts a replayed cookie jar from a real logged-in session (true of every web-cookie provider). A final live confirmation with a real qwen-web session (VPS or browser) is recommended before declaring #3288 fully closed end-to-end.

Closes #3288.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request migrates the Qwen Web provider to Alibaba's v2 chat API, implementing a two-step flow that creates a chat session before initiating a phase-based SSE stream. It updates the model catalog, captures and replays necessary WAF cookies alongside the bearer token, maps thinking phases to reasoning content, and handles expired sessions gracefully. The review feedback suggests two key improvements: updating foldMessages to fold the entire conversation history to support multi-turn chats, and passing the actual request headers to the jsonResponse helper to preserve them for logging and debugging purposes.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

The current implementation of foldMessages only captures the last user message and completely ignores any previous user messages or assistant responses in the conversation history. This breaks multi-turn conversations when routed through this single-turn provider.

To preserve conversation context, we should fold the entire history (system, user, and assistant messages) into the single prompt. If there is only a single user message, we can return its content directly to avoid unnecessary prefixes.

  private foldMessages(messages: Array<{ role: string; content: unknown }>): string {
    if (messages.length === 1 && messages[0].role === "user") {
      return String(messages[0].content ?? "");
    }
    let folded = "";
    for (const m of messages) {
      const roleName = m.role === "system" ? "System" : m.role === "user" ? "User" : "Assistant";
      const text = String(m.content ?? "");
      folded += `${roleName}: ${text}\n\n`;
    }
    return folded.trim();
  }

[gemini-code-assist]

The jsonResponse helper currently returns an empty object for headers (headers: {} as Record<string, string>). This loses the actual request headers (such as Authorization and Cookie) that were sent to the upstream API, which are highly valuable for logging, debugging, and audit trails.

We should update jsonResponse to accept the request headers and return them, matching the behavior of the streaming response branch.

  private jsonResponse(
    modelId: string,
    message: Record<string, unknown>,
    finishReason: string,
    url: string,
    headers: Record<string, string>,
    transformedBody: unknown
  ) {
    return {
      response: new Response(
        JSON.stringify({
          id: `chatcmpl-qwen-${Date.now()}`,
          object: "chat.completion",
          created: Math.floor(Date.now() / 1000),
          model: modelId,
          choices: [{ index: 0, message, finish_reason: finishReason }],
        }),
        { headers: { "Content-Type": "application/json" } }
      ),
      url,
      headers,
      transformedBody,
    };
  }

[gemini-code-assist]

Pass the actual request headers to jsonResponse so they are preserved in the execution result.

        return this.jsonResponse(
          modelId,
          message,
          finishReason,
          completionUrl,
          this.buildHeaders(token, cookieHeader, chatId),
          msgPayload
        );

[gemini-code-assist]

Pass the actual request headers to jsonResponse so they are preserved in the execution result.

      return this.jsonResponse(
        modelId,
        { role: "assistant", content: finalText },
        "stop",
        completionUrl,
        this.buildHeaders(token, cookieHeader, chatId),
        msgPayload
      );

[kilo-code-bot]

Code Review Summary

Status: 3 Issues Found (already commented) | Recommendation: Address existing feedback before merge

Overview

Severity	Count
CRITICAL	1
WARNING	2
SUGGESTION	0

Existing Inline Comments Summary

The previous review (gemini-code-assist[bot]) has already identified the following issues in open-sse/executors/qwen-web.ts:

CRITICAL (1)

File	Line	Issue
open-sse/executors/qwen-web.ts	260	foldMessages only captures the last user message and ignores assistant messages, breaking multi-turn conversation support

WARNING (2)

File	Line	Issue
open-sse/executors/qwen-web.ts	436	jsonResponse returns empty headers object instead of actual request headers needed for logging/debugging
open-sse/executors/qwen-web.ts	220, 229	jsonResponse calls do not pass the request headers parameter

Additional Observations

1. Duplicate property in message payload (line 283 and 298): The buildMessagePayload method sets parent_id: null at both the top level and inside the message object. This is redundant but harmless.

2. Reasoning content unused in non-streaming mode: The collectStream method extracts reasoning content (line 309) but it's never returned or used in the non-streaming response path. Consider including it in the response.

3. Missing XSRF_TOKEN in buildQwenCookieHeader handling: The tokenExtractionConfig captures XSRF_TOKEN cookie but buildQwenCookieHeader forwards the entire cookie jar verbatim. This is correct behavior but worth noting for clarity in documentation.

---

Note: All identified issues are already covered by existing inline comments. Please address those comments before merging.

---

_{Reviewed by laguna-m.1-20260312:free · 2,351,467 tokens}

[diegosouzapw]

Review gate: synced with release/v3.8.23 locally (clean merge), 31/31 tests green (executor-qwen-web + web-cookie-auth — covers the v2 chat API migration, cookie-jar replay and catalog update). Merging into the cycle.