Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix WebChat image recognition fails when using coding.dashscope base URL for Qwen models [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#67759•Fetched 2026-04-17 08:29:26
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
leaderlemonleaderlemon
Participants
leaderlemonleaderlemonneo1027144-creatorneo1027144-creator
Timeline (top)
referenced ×3cross-referenced ×2commented ×1

Root Cause

The function isQwen36PlusSupportedBaseUrl in models-C1cEA5eT.js hardcodes that coding.dashscope.aliyuncs.com does not support qwen3.6-plus, causing this model to be filtered out during models.json generation:

function isQwen36PlusSupportedBaseUrl(baseUrl) {
    return !isQwenCodingPlanBaseUrl(baseUrl); // coding.dashscope → false
}

This triggers a cascade:

  1. models.json missing bailian/qwen3.6-plus entry
  2. resolveGatewayModelSupportsImages in session-utils-CYl8lrsG.js cannot find the model in the catalog, returns false
  3. parseMessageWithAttachments in attachment-normalize-BDPbYB0M.js drops all attachments with a warning
  4. WebChat user sends an image + text, model only receives text

Fix Action

Fixed

PR fix notes

PR #67766: fix(gateway): fall back to explicit provider config for image capability when catalog misses [AI-assisted]

Description (problem / solution / changelog)

Summary

When using Qwen models (e.g. qwen3.6-plus) with a coding.dashscope base URL, WebChat silently discards image attachments because resolveGatewayModelSupportsImages() returns false for models missing from the built-in catalog, even when the user has explicitly configured image support.

Problem

The Qwen provider plugin filters qwen3.6-plus from the built-in catalog for coding plan URLs (since the coding plan doesn't support that model). resolveGatewayModelSupportsImages() in src/gateway/session-utils.ts only checks the built-in model catalog and hardcoded provider shims (Foundry, claude-cli). When a model is absent from the catalog, it returns false without consulting the user's explicit provider configuration (config.models.providers).

Fix

Add a fallback path: when the catalog lookup misses and no hardcoded shim matches, read loadConfig().models.providers and check if the user has explicitly defined the model with image in its input array. Catalog hits still take full precedence.

src/gateway/session-utils.ts

  • Add resolveExplicitProviderModelSupportsImages() helper and integrate it as a fallback in resolveGatewayModelSupportsImages()

src/gateway/session-utils.test.ts

  • Add 4 regression tests covering catalog hit precedence, catalog miss + explicit image config, catalog miss + text-only config, and catalog miss + no config

Testing

  • npx vitest run src/gateway/session-utils.test.ts — all tests pass (including 4 new regression tests)
  • Tested with qwen3.6-plus on coding.dashscope base URL; images are now correctly accepted

Fixes #67759

[!NOTE] This contribution was made with the assistance of AI tools (GitHub Copilot, Antigravity).

Changed files

  • src/gateway/session-utils.test.ts (modified, +134/-0)
  • src/gateway/session-utils.ts (modified, +45/-0)

PR #67768: fix(webchat): trust Qwen vision models when not found in catalog

Description (problem / solution / changelog)

Problem

When using coding.dashscope.aliyuncs.com as the base URL for a Qwen provider, images sent via the WebChat UI are silently dropped. This happens because:

  1. isQwen36PlusSupportedBaseUrl returns false for coding.dashscope base URLs
  2. buildQwenModelCatalogForBaseUrl filters out qwen3.6-plus from the catalog
  3. resolveGatewayModelSupportsImages can't find the model in the catalog and returns false
  4. parseMessageWithAttachments drops all attachments

Fix

Add a fallback in resolveGatewayModelSupportsImages that recognizes common Qwen vision model patterns regardless of provider name:

  • qwen3.6-plus
  • qwen-vl-*
  • qwen3-vl-*
  • qwen2.5-vl
  • qwen2-vl
  • qwen-vision

These are treated as image-capable even when absent from the catalog, which happens when the base URL triggers internal filtering (e.g., coding.dashscope).

Tests

Added 5 new test cases:

  • qwen3.6-plus with non-catalog provider (bailian) → true
  • qwen-vl-max not in catalog → true
  • qwen2.5-vl-72b not in catalog → true
  • Unknown non-vision model not in catalog → false (unchanged)

Closes #67759

Changed files

  • extensions/memory-core/src/dreaming-phases.ts (modified, +4/-4)
  • src/gateway/session-utils.test.ts (modified, +40/-0)
  • src/gateway/session-utils.ts (modified, +16/-0)

Code Example

function isQwen36PlusSupportedBaseUrl(baseUrl) {
    return !isQwenCodingPlanBaseUrl(baseUrl); // coding.dashscope → false
}
RAW_BUFFERClick to expand / collapse

Bug Description

When using coding.dashscope.aliyuncs.com as the base URL for a Qwen provider (e.g., the bailian provider), images sent via the WebChat UI are silently dropped and never reach the model. The model only receives the text portion of the message.

Root Cause

The function isQwen36PlusSupportedBaseUrl in models-C1cEA5eT.js hardcodes that coding.dashscope.aliyuncs.com does not support qwen3.6-plus, causing this model to be filtered out during models.json generation:

function isQwen36PlusSupportedBaseUrl(baseUrl) {
    return !isQwenCodingPlanBaseUrl(baseUrl); // coding.dashscope → false
}

This triggers a cascade:

  1. models.json missing bailian/qwen3.6-plus entry
  2. resolveGatewayModelSupportsImages in session-utils-CYl8lrsG.js cannot find the model in the catalog, returns false
  3. parseMessageWithAttachments in attachment-normalize-BDPbYB0M.js drops all attachments with a warning
  4. WebChat user sends an image + text, model only receives text

Reproduction Steps

  1. Configure a provider with baseUrl: https://coding.dashscope.aliyuncs.com/v1 in openclaw.json
  2. Include qwen3.6-plus with input: ["text", "image"] in the provider's models
  3. Open WebChat, paste an image into the input box, send a message
  4. The model responds as if no image was attached

Expected Behavior

If a model is explicitly configured in openclaw.json with input: ["text", "image"], the gateway should respect this configuration regardless of whether the model appears in the internal models.json catalog. At minimum, a warning should be shown to the user when images are dropped.

Suggested Fix

resolveGatewayModelSupportsImages in session-utils-CYl8lrsG.js should fall back to checking the explicit model configuration in openclaw.json when the model is not found in the catalog, rather than immediately returning false.

Environment

  • OpenClaw version: 2026.4.14
  • Model: bailian/qwen3.6-plus
  • Base URL: https://coding.dashscope.aliyuncs.com/v1
  • Channel: WebChat

extent analysis

TL;DR

Update the resolveGatewayModelSupportsImages function in session-utils-CYl8lrsG.js to check the explicit model configuration in openclaw.json when the model is not found in the catalog.

Guidance

  • Review the isQwen36PlusSupportedBaseUrl function in models-C1cEA5eT.js to understand why coding.dashscope.aliyuncs.com is hardcoded as not supporting qwen3.6-plus.
  • Modify the resolveGatewayModelSupportsImages function to fall back to checking the openclaw.json configuration when the model is not found in the catalog.
  • Verify that the updated function correctly handles models with input: ["text", "image"] configured in openclaw.json.
  • Test the changes with the bailian/qwen3.6-plus model and https://coding.dashscope.aliyuncs.com/v1 base URL to ensure images are no longer dropped.

Example

function resolveGatewayModelSupportsImages(model, baseUrl) {
  // Check if model is in catalog
  if (catalogHasModel(model)) {
    return true;
  }
  // Fall back to checking openclaw.json configuration
  const openclawConfig = getOpenclawConfig();
  return openclawConfig.models.includes(model) && openclawConfig.models[model].input.includes('image');
}

Notes

This fix assumes that the openclaw.json configuration takes precedence over the internal catalog. Additional testing may be necessary to ensure this change does not introduce unintended behavior.

Recommendation

Apply the suggested workaround by updating the resolveGatewayModelSupportsImages function, as this will allow the gateway to respect the explicit model configuration in openclaw.json and prevent images from being dropped.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#generation error#database connection#vector store#embedding generation#cache error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix WebChat image recognition fails when using coding.dashscope base URL for Qwen models [2 pull requests, 1 comments, 2 participants]