[Bugfix][Frontend] Accept the msgpack-numpy package's numpy markers on the OpenPI endpoint

[ZJLi2013]

Purpose

/v1/realtime/robot/openpi rejects every array packed by the msgpack-numpy PyPI package — the observation fails to decode and the client gets Invalid request payload instead of an action chunk:

ValueError: NumPy dtype marker kind mismatch: 'f' != ''

This breaks a client we ship: MolmoSpaces' DreamZeroWebsocketClient packs with that package, so examples/online_serving/dreamzero/molmospace_dreamzero_eval_demo.py cannot reach the endpoint today.

Root cause. Three dialects share the nd marker shape but disagree on kind:

Dialect	plain ndarray	kind
openpi-client	{__ndarray__, dtype, shape, data}	field absent
vLLM-native, from #4282	{nd, type, kind, shape, data}	dtype kind character, e.g. 'f'
msgpack-numpy package	{nd, type, kind, shape, data}	b'' plain, b'V' structured

_decode_vllm_numpy_marker required kind == dtype.kind, which no plain array from the package can satisfy. #4506 fixed the outbound half of this mismatch; the inbound half was listed in its suggested fix but never implemented.

Fix. Accept either spelling of kind — "" or the dtype kind character. Reject the structured form before np.dtype() runs: with kind == "V" the package puts a dtype descriptor list in type, which would otherwise surface as an opaque TypeError.

kind stays required — it is what separates an array marker from a plain user mapping (test_unpack_leaves_user_dict_without_numpy_kind_marker_unchanged pins this). Outbound packing is unchanged: replies keep the openpi-client markers.

Test Plan

vLLM Version: N/A — the fix is in the vLLM-Omni entrypoint and does not depend on the bundled vLLM version.

vLLM-Omni Commit: 03a56644, base 4ab1b4ff

CPU only, no GPU and no model load:

pytest -q tests/entrypoints/openai_api/test_openpi_connection.py

New and changed cases:

• test_unpack_msgpack_numpy_packed_observation — round-trip through the real package under importorskip. This is what would have caught the bug.
• test_unpack_accepts_msgpack_numpy_marker_dicts — hand-built kind=b"", unconditional.
• test_unpack_rejects_msgpack_numpy_structured_array_markers — structured form raises.
• The previous holder of the second name asserted the vLLM-native dialect, so it is renamed to test_unpack_accepts_vllm_native_marker_dicts. That naming is how the two dialects got conflated.

Direct reproduction of the reported failure:

pip install msgpack-numpy
python -c "
import msgpack_numpy, numpy as np
from vllm_omni.entrypoints.openpi.connection import _unpack
print(_unpack(msgpack_numpy.packb({'observation/joint_position': np.zeros(7, dtype=np.float32)})))
"

Test Result

# base 4ab1b4ff
3 failed, 12 passed

# this branch
15 passed

The repro snippet raises the ValueError above on base and prints the decoded float32 array on this branch. Environment: msgpack-numpy 0.4.8, msgpack 1.2.1, numpy 2.4.6, Python 3.12.

The real-package round-trip also covers what #5934 gives up by swapping openpi-client for a stand-in built from our own pack/unpack, and msgpack-numpy has no numpy<2 pin so it fits that CI. The two PRs are independent.

Not in scope

A compatibility fix, not a redesign of the marker handling:

• Scalars. The package's scalar branch emits {nd: False, type, data} with no kind, so it still decodes as a mapping. Fixing that means moving the discriminator off kind — e.g. onto the presence of the nd key — which reclassifies every inbound payload. Nothing in-tree hits it: DreamZero observations are arrays.
• One inbound dialect. The nd branch exists only for clients written against servers from the Support DROID policy server for Cosmos3 OpenPI #4282 era. If there are none, dropping it and keeping __ndarray__ only is less surface than maintaining two, which also matches the principle in [RFC]: Robotics Evaluation Interface Integrations #3554 that each policy takes its wire from its upstream community. Worth confirming with the author of Support DROID policy server for Cosmos3 OpenPI #4282.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[vllm-omni-review-bot]

This PR appears to belong to: docs/design/module/entrypoints.md.

Module owners: @alex-jw-brooks @linyueqian @NickCao

Please take a look when you have a chance. If you would like an automated review, mention @vllm-omni-review-bot in a comment.

[linyueqian]

Reviewed at 03a56644. This correctly accepts the empty kind emitted for plain msgpack-numpy arrays without broadening the accepted dtype set: structured, object, and complex dtypes still fail through the same dtype gates. Package scalars and decoding the outbound action markers with msgpack-numpy remain outside this change.

The tests distinguish the vLLM and msgpack-numpy marker shapes, although the real-package case is importorskip-gated when that optional dependency is absent.

CI at this head. General build 14496, Intel 7676, and NPU 6571 are green. AMD build 11272 reports failed but produced no code signal: 17 of its 20 steps ended in the errored outcome with 3 passed and not one hard failure, across eleven hours from 05:08 to 16:05 on 2026-09-01. No test body ran, so nothing was asserted on ROCm. That is the same infrastructure-expiry shape as AMD build 11401, and cycling the ready label cannot replace it, because Buildkite deduplicates per commit and a finished build still blocks its own replacement.

So the ROCm evidence here is absent rather than negative, and I am approving on the three green lanes plus static review rather than waiting on a lane that cannot re-run without a new commit. This change is msgpack decoder dtype acceptance in the frontend with no device-specific or kernel code, so ROCm has no particular opinion about it, but the gap belongs on the record.

Validation: static review of the two-file diff, the decoder failure paths, the tests, and public Buildkite step metadata for every lane. Claude Opus independently confirmed no blocking or important code defect. No fork code was executed locally.