fix(vl): raise a clear error on malformed data URLs

[SuperMarioYL]

Motivation

_load_data_url (in lmdeploy/vl/media/connection.py) parses data: URLs with two bare tuple-unpacks:

data_spec, data = url_spec_path.split(',', 1)
media_type, data_type = data_spec.split(';', 1)

A malformed data: URL that omits the comma and payload (e.g. data:image/png, data:,, data:image/png;base64) makes str.split return a single-element list, so the unpack raises an opaque ValueError: not enough values to unpack (expected 2, got 1). That error is swallowed by the surrounding except in the request path (lmdeploy/serve/core/async_engine.py) into a generic "in prompt processing error", hiding the actual cause from both the caller and the logs.

Change

Replace the bare unpacks with length-checked splits that raise a clear, debuggable ValueError at the media-loader boundary (the layer that owns data: URL parsing), pointing the caller at the expected data:<media-type>;<type>,<payload> shape:

• missing comma / empty payload → Malformed data URL: expected "data:<media-type>;<type>,<payload>" but got "data:..."
• missing ;<type> → Malformed data URL media type: expected "<media-type>;<type>" but got "..."

The existing NotImplementedError('Only base64 data URLs are supported for now.') for non-base64 payloads is unchanged. The generic catch in async_engine.py is intentionally left untouched — it now surfaces a clear root-cause message instead of an opaque unpack error.

Why a guard rather than relying on the existing catch

The generic catch already prevents the crash from surfacing as an internal error, but it converts a structural input bug into an unactionable "in prompt processing error": a caller sending data:image/png cannot tell from the response that their data URL is malformed. Raising the clear error at the loader boundary (the layer that owns data-URL parsing) is the smallest root-cause clarification at the correct layer — no engine-path change, mirroring the empty-prompt guard landed in #4803.

Tests

Added test_load_data_url_rejects_malformed (parametrized over the three malformed shapes) and test_load_data_url_loads_well_formed_base64. The malformed cases are red on main (raise not enough values to unpack, which does not match Malformed data URL) and green on this branch. Well-formed base64 loading is unchanged.

26 passed (4 new) on branch; 3 failed / 23 passed on main (the 3 new malformed cases).

Scope

Two files: lmdeploy/vl/media/connection.py (the guard) and tests/test_lmdeploy/test_vl/test_safe_url.py (the tests). No engine-layer or serving-path changes.

[Copilot]

Pull request overview

Improves robustness and debuggability of VL media loading by validating data: URL structure inside lmdeploy.vl.media.connection._load_data_url, replacing opaque tuple-unpack failures with clear, actionable ValueErrors and adding regression tests.

Changes:

• Add length-checked parsing for data: URLs and raise explicit ValueErrors for malformed shapes (missing comma/payload, missing ;<type>).
• Keep existing behavior for non-base64 data URLs (NotImplementedError) while making malformed input errors clearer.
• Add tests covering malformed data: URLs and a well-formed base64 data: URL.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
lmdeploy/vl/media/connection.py	Adds explicit validation and clearer errors for malformed data: URL parsing in _load_data_url.
tests/test_lmdeploy/test_vl/test_safe_url.py	Adds regression tests for malformed data: URLs and a well-formed base64 case.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[CUHKSZzxy]

Thanks for your contribution. I understand your intuition, but we can make it simpler for maintenance purposes.

Referring to https://github.com/vllm-project/vllm/blob/aa3100357322995b201d5348c5490596a7bd70a9/vllm/multimodal/media/connector.py#L306

We can simply raise one invalid error rather than the current over-detailed information, which I prefer. And we can also remove unit test for this improvement.

[SuperMarioYL]

Thanks for the pointer to vllm's connector. Simplified as suggested: both detailed messages are collapsed into a single concise ValueError: Invalid data URL: data:<path>, and the dedicated unit test for it has been removed (5779fc9). Happy to tweak the wording if you'd prefer it phrased differently.