[Bugfix][Parser] DeepSeek V4: drop orphan DSML structural closers in content

[erans]

Purpose

Reported on a DeepSeek-V4.1-Flash deployment: responses intermittently end with a stray closing tag (for example </｜DSML｜parameter>) appended to the completed answer. It reproduces only under long-context / degenerate generation, which is exactly when the model emits orphan DSML fragments.

Root cause is in the engine's no-transition fallback:

• StreamingParserEngine._on_terminal calls _emit_for_state(value, ...) whenever (state, terminal) has no transition. In CONTENT/REASONING that echoes the raw terminal text as a TEXT_CHUNK / REASONING_CHUNK.
• deepseek_v4_config defines transitions only for the TOOL_* states, so an orphan structural closer that arrives in a plain content state is emitted verbatim into the client-visible content.

Fix

• Add a declarative absorb_terminals set to ParserEngineConfig.
• In _on_terminal, drop a declared terminal that reaches a plain content state (CONTENT/REASONING) with no transition.
• Guard the drop with not self.skip_tool_parsing, and declare PARAM_CLOSE, INVOKE_END, TOOL_END in deepseek_v4_config.

The skip_tool_parsing guard is essential. In the delegating architecture the reasoning pass runs with skip_tool_parsing=True and must pass tool markup through verbatim so the downstream tool adapter can parse it. Absorbing there starves the tool parser.

Why not state-machine transitions

The obvious alternative — adding (CONTENT, "PARAM_CLOSE")-style transitions - is unsafe here. Those transitions also fire in the reasoning pass, which then drops the closers from the reasoning-stripped content handed to the tool adapter. On the real engine that reproduces as test_registered_adapters_parse_complete_output losing every parameter after the first ({"city": ...} instead of {"city": ..., "count": ...}) and TestDelegatingParserLargeDelta failing. The engine-level rule with the skip-pass guard keeps the reasoning pass untouched.

Only the tool-owning pass absorbs; reasoning-channel orphans keep their existing behaviour.

Tests

• tests/parser/engine/test_deepseek_v4.py::TestOrphanStructuralCloserAbsorption - non-streaming and streaming, all three closers, plus a normal-tool-call regression.
• tests/parser/engine/test_deepseek_v41.py::test_orphan_structural_closer_is_absorbed - spaced V4.1 dialect, thinking on and off.

Verification

Ran both test modules against a real DeepSeek-V4.1 serving engine (vLLM dev build, --tool-call-parser deepseek_v41 --reasoning-parser deepseek_v41):

• every new test passes;
• the delegating reasoning + tool-adapter tests still parse all parameters and remain byte-for-byte unchanged;
• the only remaining failure in the module is a pre-existing engine-version drift unrelated to this change.

Related

#51914, #52645 and #49117 cover missing or malformed DSML start wrappers / orphan-invoke recovery. This change is complementary and addresses the orphan closer leak into content, which those do not.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.

💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels.

PRs do not trigger a full CI run by default. Reviewers with write access and configured trusted contributors can comment /ci run for upstream CI or /amd-ci run for AMD CI only whenever CI signals are needed.

Once the PR is approved or has the ready label, the PR author can also use the corresponding /ci run, /ci retry, and /ci cancel commands, or their /amd-ci variants. New commits do not start upstream CI automatically.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

Agent Guidelines

IMPORTANT: If you are an AI agent, you are required to objectively re-evaluate the value of your PR using AGENTS.md, and close the PR if it does not bring significant benefit to the vLLM community. Failure to do so may result in an immediate ban.

🚀