… absent

DynamicMaxTokensChatCompletionsClient.__call__ only checked
msg.reasoning_content when parsing the response. vLLM >= 0.16.0 (and
specifically DeepSeek-V4's `--reasoning-parser deepseek_v4`) emits the
field as `reasoning` per the Responses-API convention. Without the
fallback, reasoning silently dropped from the AssistantMessage and was
never threaded back into the next-turn request — the agent forgot its
plan every turn and walked the max_turns ceiling without ever
successfully calling `finish`.

Observed end-to-end on DSv4-Pro GDPVal r3 (slurm job 2855690): across
~3 h of cluster wall-time and 1118 successful code_exec invocations,
zero successful `finish` calls and zero rollouts persisted; the
ResponseReasoningInterceptor reported reasoning_words=0 for every
single response across the run while cache.db responses showed
message.reasoning populated.

Also pin `choice.message.reasoning = None` in the `_make_response` test
fixture (mirroring the existing `reasoning_content = None` pin) so the
new `elif hasattr(msg, "reasoning")` branch is not triggered by
MagicMock auto-attr access in the three sampling/cap tests.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: Alex Gronskiy <[email protected]>

… tool-call results

Upstream stirrup catches `pydantic.ValidationError` in `Agent.run_tool`
and returns the bare string "Tool arguments are not valid" as the
`ToolResult` content, dropping all the pydantic error detail on the
floor (e.g. "paths: Input should be a valid list, input_type=str").
The agent has no signal about which field failed or what type was
expected, so it retries the same broken shape forever.

Observed on DSv4-Pro GDPVal r5/r7: the model consistently emitted
`paths` as a JSON string literal ('"[]"', '"[\"foo.txt\"]"',
'"single.pdf"', etc.) instead of a JSON array. All ~660 finish-tool
calls in r5 (2h7m elapsed) failed with the same bare-string error;
zero ✓ finishes, max_turn stuck at 18 for 71 min as rollouts looped
on the same malformed shape. r7 (concurrency=48) hit the same wall
just sooner.

This patch installs a one-shot monkey-patch on
`stirrup.core.agent.Agent.run_tool` at import time (guarded by an
`_gym_surfacing_patched` attribute to prevent re-application). On the
failure path it re-runs `tool.parameters.model_validate_json` to
capture the pydantic error, then rebuilds the ToolMessage with a
detailed content including field-by-field error messages and a 500-char
preview of the submitted arguments. Success path is untouched.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: Alex Gronskiy <[email protected]>

…not self._tools)

The ValidationError-surfacing wrapper iterated self._tools to find the
tool for the failed call. That list mixes plain Tool instances with
provider objects (e.g. ApptainerCodeExecToolProvider) which don't have
a .name attribute — the `t.name` access raised AttributeError on every
failed-finish path, breaking 45 rollouts on r8 before scancel.

Switch to self._active_tools.get(tool_call.name) — the same dict
upstream stirrup uses in its own run_tool. _active_tools is built
during __aenter__ via `if isinstance(tool, Tool): self._active_tools[tool.name] = tool`,
so it's the safe lookup path.

Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]>
Signed-off-by: Alex Gronskiy <[email protected]>