Bump mockserver-client from 6.1.0 to 7.1.0

[dependabot]

Bumps mockserver-client from 6.1.0 to 7.1.0.

Release notes

Sourced from mockserver-client's releases.

MockServer 7.1.0

[7.1.0] - 2026-06-15

Added

Verification

• Verify responses received from proxied/forwarded systems — verification now optionally matches the response of a recorded request-response exchange, not just the request. Add an httpResponse matcher to a verification (PUT /mockserver/verify with {httpRequest?, httpResponse, times}) and MockServer counts recorded request-response pairs (proxied/forwarded exchanges) whose response matches — by status code, reason phrase (regex), headers, and body (JSON, JSON schema, JSONPath, XML, XPath, regex, etc., reusing the existing request body matchers). When httpRequest is also supplied, both must match. verifySequence gains an index-aligned httpResponses list so an ordered sequence can assert on responses too. The verify/verifySequence call shape and VerificationTimes are unchanged — the presence of a response matcher is what switches verification from "request received" to "response received". When no response matcher is supplied, behaviour is identical to before.

Breakpoints & request replay

• Matcher-driven breakpoints — breakpoints are toggled per-request via a matcher rather than by global config flags. You register a request matcher (works exactly like an expectation request matcher) together with the phases to break at: PUT /mockserver/breakpoint/matcher with {httpRequest, phases:["REQUEST"|"RESPONSE"|"RESPONSE_STREAM"|"INBOUND_STREAM"], clientId:"..."}. A forwarded/proxied exchange whose request matches a registered breakpoint pauses at the selected phase(s). Manage matchers via GET/PUT /mockserver/breakpoint/matchers, PUT /mockserver/breakpoint/matcher/remove ({id}), and PUT /mockserver/breakpoint/matcher/clear; the registry is cleared on /mockserver/reset. The breakpointTimeoutMillis (30000) and breakpointMaxHeld (50) safety rails are retained.
• clientId required for breakpoint registration; callback WebSocket is the resolution transport — PUT /mockserver/breakpoint/matcher requires a clientId field (the callback WebSocket client id); omitting it returns 400. Breakpoints are resolved interactively over the callback WebSocket only — all clients (including the dashboard) resolve breakpoints over that channel.
• Interactive breakpoint resolution over the callback WebSocket — a matching forwarded REQUEST or RESPONSE exchange is dispatched to the owning callback-WebSocket client (the same /_mockserver_callback_websocket channel forwardObject/responseObject clients use) for interactive resolution: the client replies with a modified request (forward), a response (abort/replace), or the original (continue). Shares the breakpointTimeoutMillis auto-continue and breakpointMaxHeld cap rails; a client disconnect removes its breakpoints and auto-continues anything it was holding.
• Per-frame streaming breakpoints over the callback WebSocket — RESPONSE_STREAM (outbound) and INBOUND_STREAM (client→server) breakpoints resolve interactively over the callback WebSocket across all nine streaming hold points (SSE/chunked, HTTP/3 gRPC, gRPC server-streaming, WebSocket eager/bidi, GraphQL-subscription, and the WebSocket/GraphQL/gRPC-bidi inbound paths). Two WS message types form the frozen per-frame protocol: a server→client PausedStreamFrameDTO (correlationId, streamId, sequenceNumber, direction, phase, base64 body, request method/path) and a client→server StreamFrameDecisionDTO (correlationId, action ∈ CONTINUE/MODIFY/DROP/INJECT/CLOSE, optional base64 body). Event-loop safe (decisions marshalled onto the channel event loop, frame bytes copied to byte[]), with ordering and backpressure preserved and the shared timeout/max-held rails + client-disconnect auto-continue. The per-server WebSocket registry is injected per-channel (no process-global state).
• Java client breakpoint API (matcher + callback handlers) — MockServerClient.addBreakpoint(matcher, phases…, handlers…) registers a breakpoint matcher and resolves paused exchanges interactively over the callback WebSocket, with typed handlers per phase: BreakpointRequestHandler (return a request to forward/modify or a response to abort), BreakpointResponseHandler (return the response to write), and BreakpointStreamFrameHandler (return a CONTINUE/MODIFY/DROP/INJECT/CLOSE decision). Plus listBreakpointMatchers(), removeBreakpointMatcher(id), clearBreakpointMatchers(). The client lazily opens one callback-WS connection (reused across breakpoints) and tears it down on stop/reset. Per-matcher handler routing: each pushed paused item carries the matched breakpoint's id (a new X-MockServer-BreakpointId header for request/response and a breakpointId field on the stream-frame message), so each breakpoint routes to its own handler rather than a single shared per-phase handler. This is the reference API the other language clients mirror.
• Node, Python & Ruby client breakpoint APIs — the Node, Python, and Ruby clients gain the same matcher-driven breakpoint API as the Java client (addBreakpoint/add_breakpoint + convenience overloads, list/remove/clear breakpoint matchers), resolving paused request/response/stream-frame exchanges interactively over each client's existing callback WebSocket with per-matcher handler routing (by the X-MockServer-BreakpointId header / breakpointId frame field). Idiomatic per language (typed objects in Node, dicts in Python, hashes in Ruby); handlers auto-continue on error or missing handler so a buggy handler can't hang the exchange.
• Go, .NET & Rust client breakpoint APIs (new callback-WebSocket stacks) — the Go, .NET, and Rust clients gain a full callback-WebSocket stack (Go gorilla/websocket, .NET built-in ClientWebSocket, Rust tungstenite) plus the matcher-driven breakpoint API (addBreakpoint/AddBreakpoint/add_breakpoint + convenience overloads, list/remove/clear breakpoint matchers). Each connects to /_mockserver_callback_websocket, registers a clientId, and resolves paused request/response/stream-frame exchanges over the callback WebSocket with per-matcher handler routing, auto-continuing on handler error/panic. Concurrency-safe (serialised WS writes + lazy init; Go verified with -race) and reconnect-on-dead-connection. PHP is excluded (no WebSocket support). This completes breakpoint support across seven clients (Java, Node, Python, Ruby, Go, .NET, Rust).
• Stream frame breakpoints (backend) — per-frame hold/modify/drop/inject/close for all streaming response types: forwarded SSE/HTTP/1.1 chunked, gRPC server-streaming, WebSocket, GraphQL-subscription, and HTTP/3 gRPC. Each frame is intercepted at its hold point, parked in StreamFrameBreakpointRegistry, and resolved over the callback WebSocket. Fully non-blocking (event-loop safe), with backpressure, ordered frame resolution, stream-close eviction, timeout auto-continue, and the shared breakpointMaxHeld cap. Activated when a matching RESPONSE_STREAM breakpoint matcher is registered (zero overhead otherwise).
• Inbound (client→server) breakpoints for gRPC bidi over HTTP/3 (QUIC) — extends INBOUND_STREAM breakpoints to bidirectional gRPC streaming over HTTP/3, the QUIC analogue of the HTTP/2 gRPC-bidi inbound path (Http3GrpcBidiStreamHandler). Each inbound gRPC DATA frame is parked before decoding and resolved over the callback WebSocket (continue/modify/drop/inject/close); default-off (only when an INBOUND_STREAM matcher matches the stream). Because the QUIC driver copies each frame to byte[] and releases it before handing off, no ByteBuf is held and the QUIC flow-control window is never pinned; per-frame ordering is preserved by dispatching one frame at a time and buffering the rest (bounded by maxRequestBodySize). This completes interactive breakpoints across HTTP/1.1, HTTP/2, and HTTP/3.
• Dashboard Breakpoints panel (callback-WebSocket client) — the dashboard is a real callback client: it connects to /_mockserver_callback_websocket (the server assigns it a clientId, since a browser WebSocket can't send the registration header) and resolves paused exchanges live over the callback WebSocket — no REST polling. The panel has three tabs: Matchers (register a breakpoint matcher with a method/path matcher + phase checkboxes; list/remove/clear), Live Exchanges (paused requests/responses arrive in real time — Continue / Modify the JSON / Abort), and Live Streams (paused stream frames — Continue / Modify / Drop / Inject / Close; direction badge distinguishes INBOUND from OUTBOUND frames). A connection-state indicator shows the callback-WS status.
• Request replay from the dashboard — a new PUT /mockserver/replay control-plane endpoint re-issues a previously recorded/proxied request to its original target and returns the upstream response (reuses the existing NettyHttpClient/forward client; 10 MB body-size cap; behind control-plane auth). The dashboard Traffic view gains a Replay button on every selected request that opens a dialog to re-issue the request with one click and inspect the live response. The Java client exposes a typed replay(HttpRequest) method wrapping the endpoint.
• Inbound bidirectional frame breakpoints (backend) — intercepts client-to-server frames on WebSocket, GraphQL-subscription, and gRPC-bidi connections before MockServer processes them. Each inbound frame is copied to byte[], the original ByteBuf/Http2DataFrame is released immediately (refunding the HTTP/2 flow-control window), and the copy is parked in StreamFrameBreakpointRegistry with direction=INBOUND. Resolved over the callback WebSocket. Fully non-blocking with backpressure (autoRead paused for WebSocket/GraphQL; pull-based ctx.read() withholding for gRPC-bidi), channel-close eviction. Activated when a matching INBOUND_STREAM breakpoint matcher is registered (zero overhead otherwise).

OpenAPI

• Full OpenAPI 3.1 support — MockServer now fully supports OpenAPI 3.1 specifications, including the three constructs previously documented as partially handled: type as an array (e.g. type: [string, "null"]) now generates correct example values for the primary non-null type; $ref siblings (description alongside $ref) are resolved by the parser; and the webhooks top-level key is parsed and its operations are included when generating expectations, matching requests, and validating responses. No specification changes or version downgrades are required.

Chaos engineering

• Scheduled multi-stage chaos experiments — a new PUT /mockserver/chaosExperiment endpoint starts an ordered sequence of chaos stages, each applying service-scoped chaos profiles for a configurable duration before automatically advancing to the next stage. Supports looping, status polling via GET /mockserver/chaosExperiment, graceful stop via DELETE /mockserver/chaosExperiment, and integrates with the C1 auto-halt circuit-breaker (an experiment halts if the safety threshold is exceeded mid-stage). Max 50 stages, 24 h per stage, one active experiment at a time.
• Chaos auto-halt circuit-breaker — when enabled (chaosAutoHaltEnabled=true), MockServer automatically disables all active service-scoped chaos profiles if the number of chaos-injected errors within a sliding window exceeds a configurable threshold, preventing chaos experiments from causing cascading outages. Reflected in the mock_server_chaos_auto_halt_total Prometheus counter and a WARN log event.
• Dashboard Chaos tab — full HTTP fault-type controls — the HTTP Service Chaos register/edit form now exposes every HttpChaosProfile field: Retry-After header, body truncation fraction, malformed body toggle, slow (dribbled) response chunk size/delay, quota rate-limiting (name/limit/window/error status), degradation ramp, and outage time window — so users can configure the complete fault set without writing JSON.

LLM observability & cost control

• LLM proxy/forward observability — observability that previously fired only for mocked LLM responses now also covers LLM traffic forwarded/proxied through MockServer. With otelTracesEnabled, MockServer emits a GenAI OpenTelemetry span (provider, model, token usage, finish reason) for forwarded LLM responses, using a new provider sniffer that detects the upstream from the target host (with a path-gated fallback to llmProvider); all forward paths (matched-forward, unmatched proxy-pass, breakpoint-continuation) now also emit the generic request span consistently. The agent-run analysis tools (explain_agent_run, verify_tool_call) accept provider:"AUTO" for provider auto-detection from recorded request paths, and the dashboard Sessions view renders the call graph for proxy-only sessions, grouping unscoped traffic by upstream host. Off by default; fully fail-soft (telemetry never affects the forwarded response).
• LLM token/cost Prometheus metrics — when llmMetricsEnabled=true (alongside metricsEnabled), three new Prometheus counters track cumulative LLM token usage and estimated cost across all served and forwarded completions: mock_server_llm_input_tokens, mock_server_llm_output_tokens, mock_server_llm_cost_usd, each labeled by provider and model. The forward-path response parse is gated on metrics OR tracing OR budget, so token tracking works without requiring full OTLP tracing. Default off to avoid parsing forwarded response bodies unless asked.
• LLM cost-budget circuit-breaker — mockserver.llmCostBudgetUsd sets a cumulative USD ceiling across all LLM completions (mocked + forwarded). When the running cost total exceeds the budget, unmatched LLM proxy forwards are blocked with a 429 response including the cumulative and budget amounts (mocked LLM responses are never blocked). Deterministic and fail-open (a negative, unset, or malformed budget never blocks traffic). Resets on HttpState.reset(). Tracked by the mock_server_llm_cost_budget_tripped Prometheus counter.
• Per-session token/cost totals in Sessions view — the dashboard Sessions view now displays per-session aggregate token usage (total input/output tokens) and estimated USD cost as chips in each session lane header, computed purely client-side from the already-parsed response bodies.
• First-class LLM failover/retry scenario builder — LlmFailoverBuilder and the mock_llm_failover MCP tool generate an ordered set of expectations that simulate a provider returning failures (e.g. 503, 429) for the first N attempts, then succeeding with a provider-correct httpLlmResponse. Uses Times.exactly(n) on failure expectations so they are consumed in order before falling through to the unlimited success expectation. Consecutive same-status failures are coalesced for efficiency. Point LiteLLM, Envoy AI Gateway, or an SDK's retry config at MockServer and assert failover logic deterministically.
• Token-based (TPM/TPD) LLM rate-limit simulation — LlmChaosProfile now supports token-based quota enforcement via tokenQuotaLimit and tokenQuotaWindowMillis, modelling real provider TPM/TPD limits. Each response's token count (from Usage or estimated from text length) is charged against an independent fixed-window counter in LlmQuotaRegistry; when the cumulative in-window total exceeds the limit, a 429 (token_quota_exceeded) is returned. Both request-count and token quotas can coexist on the same profile.
• Provider-correct LLM rate-limit response headers — when MockServer returns a rate-limit or quota error on the LLM response path (probabilistic chaos errorStatus or stateful quota 429), it now emits the provider-correct rate-limit HTTP headers that real LLM providers send (OpenAI x-ratelimit-limit-requests/x-ratelimit-remaining-requests/x-ratelimit-reset-requests, Anthropic anthropic-ratelimit-requests-* with RFC 3339 timestamps, Gemini/Bedrock retry-after). Successful responses also carry the headers when a quota is configured, so client SDK retry/backoff logic can be exercised against a mock. Ollama returns no rate-limit headers (local inference). Implemented by the pure helper LlmRateLimitHeaders (org.mockserver.llm).

Mock creation & matching feedback

• Generalised capture-to-expectation — the dashboard "Capture as Mock" dialog now works for any recorded or proxied request (plain HTTP, gRPC, GraphQL), not just LLM traffic. A three-level matcher precision toggle (Exact / Moderate / Loose) controls how tightly the generated httpRequest matcher binds: from method+path+query+headers+body down to method+path only. Generic captures register via PUT /mockserver/expectation with httpResponse; the existing LLM capture path is unchanged.
• Create expectation from unmatched request — the "Why Didn't This Match?" mismatch diagnostic dialog now includes a "Create Expectation" button that opens the capture-as-mock dialog pre-filled with the unmatched request, letting users turn a near-miss into a working stub in one click.
• Client-visible match feedback — new opt-in config property attachMismatchDiagnosticToResponse (default false) attaches closest-match diagnostic info (header x-mockserver-closest-match + JSON body with per-field diffs) to 404 responses for unmatched requests, so test authors can see why their mock didn't match without checking the dashboard or logs.
• Opt-in realistic OpenAPI example data — new config property generateRealisticExampleValues (default false) makes OpenAPI example generation produce schema/format-aware values via Datafaker (email, UUID, date, date-time, URI, hostname, IPv4/IPv6, byte, password, integers/numbers respecting min/max) instead of static placeholders, with a fixed seed for deterministic output. Existing behaviour is unchanged when the flag is off.

Response templates

• Templates can be loaded from a file — httpResponseTemplate and httpForwardTemplate accept a new templateFile field (a classpath-or-filesystem path) as an alternative to the inline template, keeping large templates out of the expectation JSON. When both are set the inline template takes precedence. Works with all three engines (Velocity, Mustache, JavaScript).
• Templated response body files — a static httpResponse whose body is a FILE body can set a templateType of MUSTACHE or VELOCITY, in which case the file contents are rendered as a template against the request before being returned (the status code, headers and content type still come from the static response). This combines externally stored response bodies (issue #2163) with response templating, as requested in discussion #2350. JavaScript is not supported for body files (its templates return a full response object rather than text) — use httpResponseTemplate for that.
• Client-library support for templateFile and templated FILE bodies — the Node, Python, Go, .NET, Ruby and Rust clients gain templateFile on their template models and templateType on FILE response bodies, so the two features above can be driven from each client (the PHP client, which has no template model, gains a fileBody() helper).

... (truncated)

Changelog

Sourced from mockserver-client's changelog.

[7.1.0] - 2026-06-15

Added

Verification

• Verify responses received from proxied/forwarded systems — verification now optionally matches the response of a recorded request-response exchange, not just the request. Add an httpResponse matcher to a verification (PUT /mockserver/verify with {httpRequest?, httpResponse, times}) and MockServer counts recorded request-response pairs (proxied/forwarded exchanges) whose response matches — by status code, reason phrase (regex), headers, and body (JSON, JSON schema, JSONPath, XML, XPath, regex, etc., reusing the existing request body matchers). When httpRequest is also supplied, both must match. verifySequence gains an index-aligned httpResponses list so an ordered sequence can assert on responses too. The verify/verifySequence call shape and VerificationTimes are unchanged — the presence of a response matcher is what switches verification from "request received" to "response received". When no response matcher is supplied, behaviour is identical to before.

Breakpoints & request replay

• Matcher-driven breakpoints — breakpoints are toggled per-request via a matcher rather than by global config flags. You register a request matcher (works exactly like an expectation request matcher) together with the phases to break at: PUT /mockserver/breakpoint/matcher with {httpRequest, phases:["REQUEST"|"RESPONSE"|"RESPONSE_STREAM"|"INBOUND_STREAM"], clientId:"..."}. A forwarded/proxied exchange whose request matches a registered breakpoint pauses at the selected phase(s). Manage matchers via GET/PUT /mockserver/breakpoint/matchers, PUT /mockserver/breakpoint/matcher/remove ({id}), and PUT /mockserver/breakpoint/matcher/clear; the registry is cleared on /mockserver/reset. The breakpointTimeoutMillis (30000) and breakpointMaxHeld (50) safety rails are retained.
• clientId required for breakpoint registration; callback WebSocket is the resolution transport — PUT /mockserver/breakpoint/matcher requires a clientId field (the callback WebSocket client id); omitting it returns 400. Breakpoints are resolved interactively over the callback WebSocket only — all clients (including the dashboard) resolve breakpoints over that channel.
• Interactive breakpoint resolution over the callback WebSocket — a matching forwarded REQUEST or RESPONSE exchange is dispatched to the owning callback-WebSocket client (the same /_mockserver_callback_websocket channel forwardObject/responseObject clients use) for interactive resolution: the client replies with a modified request (forward), a response (abort/replace), or the original (continue). Shares the breakpointTimeoutMillis auto-continue and breakpointMaxHeld cap rails; a client disconnect removes its breakpoints and auto-continues anything it was holding.
• Per-frame streaming breakpoints over the callback WebSocket — RESPONSE_STREAM (outbound) and INBOUND_STREAM (client→server) breakpoints resolve interactively over the callback WebSocket across all nine streaming hold points (SSE/chunked, HTTP/3 gRPC, gRPC server-streaming, WebSocket eager/bidi, GraphQL-subscription, and the WebSocket/GraphQL/gRPC-bidi inbound paths). Two WS message types form the frozen per-frame protocol: a server→client PausedStreamFrameDTO (correlationId, streamId, sequenceNumber, direction, phase, base64 body, request method/path) and a client→server StreamFrameDecisionDTO (correlationId, action ∈ CONTINUE/MODIFY/DROP/INJECT/CLOSE, optional base64 body). Event-loop safe (decisions marshalled onto the channel event loop, frame bytes copied to byte[]), with ordering and backpressure preserved and the shared timeout/max-held rails + client-disconnect auto-continue. The per-server WebSocket registry is injected per-channel (no process-global state).
• Java client breakpoint API (matcher + callback handlers) — MockServerClient.addBreakpoint(matcher, phases…, handlers…) registers a breakpoint matcher and resolves paused exchanges interactively over the callback WebSocket, with typed handlers per phase: BreakpointRequestHandler (return a request to forward/modify or a response to abort), BreakpointResponseHandler (return the response to write), and BreakpointStreamFrameHandler (return a CONTINUE/MODIFY/DROP/INJECT/CLOSE decision). Plus listBreakpointMatchers(), removeBreakpointMatcher(id), clearBreakpointMatchers(). The client lazily opens one callback-WS connection (reused across breakpoints) and tears it down on stop/reset. Per-matcher handler routing: each pushed paused item carries the matched breakpoint's id (a new X-MockServer-BreakpointId header for request/response and a breakpointId field on the stream-frame message), so each breakpoint routes to its own handler rather than a single shared per-phase handler. This is the reference API the other language clients mirror.
• Node, Python & Ruby client breakpoint APIs — the Node, Python, and Ruby clients gain the same matcher-driven breakpoint API as the Java client (addBreakpoint/add_breakpoint + convenience overloads, list/remove/clear breakpoint matchers), resolving paused request/response/stream-frame exchanges interactively over each client's existing callback WebSocket with per-matcher handler routing (by the X-MockServer-BreakpointId header / breakpointId frame field). Idiomatic per language (typed objects in Node, dicts in Python, hashes in Ruby); handlers auto-continue on error or missing handler so a buggy handler can't hang the exchange.
• Go, .NET & Rust client breakpoint APIs (new callback-WebSocket stacks) — the Go, .NET, and Rust clients gain a full callback-WebSocket stack (Go gorilla/websocket, .NET built-in ClientWebSocket, Rust tungstenite) plus the matcher-driven breakpoint API (addBreakpoint/AddBreakpoint/add_breakpoint + convenience overloads, list/remove/clear breakpoint matchers). Each connects to /_mockserver_callback_websocket, registers a clientId, and resolves paused request/response/stream-frame exchanges over the callback WebSocket with per-matcher handler routing, auto-continuing on handler error/panic. Concurrency-safe (serialised WS writes + lazy init; Go verified with -race) and reconnect-on-dead-connection. PHP is excluded (no WebSocket support). This completes breakpoint support across seven clients (Java, Node, Python, Ruby, Go, .NET, Rust).
• Stream frame breakpoints (backend) — per-frame hold/modify/drop/inject/close for all streaming response types: forwarded SSE/HTTP/1.1 chunked, gRPC server-streaming, WebSocket, GraphQL-subscription, and HTTP/3 gRPC. Each frame is intercepted at its hold point, parked in StreamFrameBreakpointRegistry, and resolved over the callback WebSocket. Fully non-blocking (event-loop safe), with backpressure, ordered frame resolution, stream-close eviction, timeout auto-continue, and the shared breakpointMaxHeld cap. Activated when a matching RESPONSE_STREAM breakpoint matcher is registered (zero overhead otherwise).
• Inbound (client→server) breakpoints for gRPC bidi over HTTP/3 (QUIC) — extends INBOUND_STREAM breakpoints to bidirectional gRPC streaming over HTTP/3, the QUIC analogue of the HTTP/2 gRPC-bidi inbound path (Http3GrpcBidiStreamHandler). Each inbound gRPC DATA frame is parked before decoding and resolved over the callback WebSocket (continue/modify/drop/inject/close); default-off (only when an INBOUND_STREAM matcher matches the stream). Because the QUIC driver copies each frame to byte[] and releases it before handing off, no ByteBuf is held and the QUIC flow-control window is never pinned; per-frame ordering is preserved by dispatching one frame at a time and buffering the rest (bounded by maxRequestBodySize). This completes interactive breakpoints across HTTP/1.1, HTTP/2, and HTTP/3.
• Dashboard Breakpoints panel (callback-WebSocket client) — the dashboard is a real callback client: it connects to /_mockserver_callback_websocket (the server assigns it a clientId, since a browser WebSocket can't send the registration header) and resolves paused exchanges live over the callback WebSocket — no REST polling. The panel has three tabs: Matchers (register a breakpoint matcher with a method/path matcher + phase checkboxes; list/remove/clear), Live Exchanges (paused requests/responses arrive in real time — Continue / Modify the JSON / Abort), and Live Streams (paused stream frames — Continue / Modify / Drop / Inject / Close; direction badge distinguishes INBOUND from OUTBOUND frames). A connection-state indicator shows the callback-WS status.
• Request replay from the dashboard — a new PUT /mockserver/replay control-plane endpoint re-issues a previously recorded/proxied request to its original target and returns the upstream response (reuses the existing NettyHttpClient/forward client; 10 MB body-size cap; behind control-plane auth). The dashboard Traffic view gains a Replay button on every selected request that opens a dialog to re-issue the request with one click and inspect the live response. The Java client exposes a typed replay(HttpRequest) method wrapping the endpoint.
• Inbound bidirectional frame breakpoints (backend) — intercepts client-to-server frames on WebSocket, GraphQL-subscription, and gRPC-bidi connections before MockServer processes them. Each inbound frame is copied to byte[], the original ByteBuf/Http2DataFrame is released immediately (refunding the HTTP/2 flow-control window), and the copy is parked in StreamFrameBreakpointRegistry with direction=INBOUND. Resolved over the callback WebSocket. Fully non-blocking with backpressure (autoRead paused for WebSocket/GraphQL; pull-based ctx.read() withholding for gRPC-bidi), channel-close eviction. Activated when a matching INBOUND_STREAM breakpoint matcher is registered (zero overhead otherwise).

OpenAPI

• Full OpenAPI 3.1 support — MockServer now fully supports OpenAPI 3.1 specifications, including the three constructs previously documented as partially handled: type as an array (e.g. type: [string, "null"]) now generates correct example values for the primary non-null type; $ref siblings (description alongside $ref) are resolved by the parser; and the webhooks top-level key is parsed and its operations are included when generating expectations, matching requests, and validating responses. No specification changes or version downgrades are required.

Chaos engineering

• Scheduled multi-stage chaos experiments — a new PUT /mockserver/chaosExperiment endpoint starts an ordered sequence of chaos stages, each applying service-scoped chaos profiles for a configurable duration before automatically advancing to the next stage. Supports looping, status polling via GET /mockserver/chaosExperiment, graceful stop via DELETE /mockserver/chaosExperiment, and integrates with the C1 auto-halt circuit-breaker (an experiment halts if the safety threshold is exceeded mid-stage). Max 50 stages, 24 h per stage, one active experiment at a time.
• Chaos auto-halt circuit-breaker — when enabled (chaosAutoHaltEnabled=true), MockServer automatically disables all active service-scoped chaos profiles if the number of chaos-injected errors within a sliding window exceeds a configurable threshold, preventing chaos experiments from causing cascading outages. Reflected in the mock_server_chaos_auto_halt_total Prometheus counter and a WARN log event.
• Dashboard Chaos tab — full HTTP fault-type controls — the HTTP Service Chaos register/edit form now exposes every HttpChaosProfile field: Retry-After header, body truncation fraction, malformed body toggle, slow (dribbled) response chunk size/delay, quota rate-limiting (name/limit/window/error status), degradation ramp, and outage time window — so users can configure the complete fault set without writing JSON.

LLM observability & cost control

• LLM proxy/forward observability — observability that previously fired only for mocked LLM responses now also covers LLM traffic forwarded/proxied through MockServer. With otelTracesEnabled, MockServer emits a GenAI OpenTelemetry span (provider, model, token usage, finish reason) for forwarded LLM responses, using a new provider sniffer that detects the upstream from the target host (with a path-gated fallback to llmProvider); all forward paths (matched-forward, unmatched proxy-pass, breakpoint-continuation) now also emit the generic request span consistently. The agent-run analysis tools (explain_agent_run, verify_tool_call) accept provider:"AUTO" for provider auto-detection from recorded request paths, and the dashboard Sessions view renders the call graph for proxy-only sessions, grouping unscoped traffic by upstream host. Off by default; fully fail-soft (telemetry never affects the forwarded response).
• LLM token/cost Prometheus metrics — when llmMetricsEnabled=true (alongside metricsEnabled), three new Prometheus counters track cumulative LLM token usage and estimated cost across all served and forwarded completions: mock_server_llm_input_tokens, mock_server_llm_output_tokens, mock_server_llm_cost_usd, each labeled by provider and model. The forward-path response parse is gated on metrics OR tracing OR budget, so token tracking works without requiring full OTLP tracing. Default off to avoid parsing forwarded response bodies unless asked.
• LLM cost-budget circuit-breaker — mockserver.llmCostBudgetUsd sets a cumulative USD ceiling across all LLM completions (mocked + forwarded). When the running cost total exceeds the budget, unmatched LLM proxy forwards are blocked with a 429 response including the cumulative and budget amounts (mocked LLM responses are never blocked). Deterministic and fail-open (a negative, unset, or malformed budget never blocks traffic). Resets on HttpState.reset(). Tracked by the mock_server_llm_cost_budget_tripped Prometheus counter.
• Per-session token/cost totals in Sessions view — the dashboard Sessions view now displays per-session aggregate token usage (total input/output tokens) and estimated USD cost as chips in each session lane header, computed purely client-side from the already-parsed response bodies.
• First-class LLM failover/retry scenario builder — LlmFailoverBuilder and the mock_llm_failover MCP tool generate an ordered set of expectations that simulate a provider returning failures (e.g. 503, 429) for the first N attempts, then succeeding with a provider-correct httpLlmResponse. Uses Times.exactly(n) on failure expectations so they are consumed in order before falling through to the unlimited success expectation. Consecutive same-status failures are coalesced for efficiency. Point LiteLLM, Envoy AI Gateway, or an SDK's retry config at MockServer and assert failover logic deterministically.
• Token-based (TPM/TPD) LLM rate-limit simulation — LlmChaosProfile now supports token-based quota enforcement via tokenQuotaLimit and tokenQuotaWindowMillis, modelling real provider TPM/TPD limits. Each response's token count (from Usage or estimated from text length) is charged against an independent fixed-window counter in LlmQuotaRegistry; when the cumulative in-window total exceeds the limit, a 429 (token_quota_exceeded) is returned. Both request-count and token quotas can coexist on the same profile.
• Provider-correct LLM rate-limit response headers — when MockServer returns a rate-limit or quota error on the LLM response path (probabilistic chaos errorStatus or stateful quota 429), it now emits the provider-correct rate-limit HTTP headers that real LLM providers send (OpenAI x-ratelimit-limit-requests/x-ratelimit-remaining-requests/x-ratelimit-reset-requests, Anthropic anthropic-ratelimit-requests-* with RFC 3339 timestamps, Gemini/Bedrock retry-after). Successful responses also carry the headers when a quota is configured, so client SDK retry/backoff logic can be exercised against a mock. Ollama returns no rate-limit headers (local inference). Implemented by the pure helper LlmRateLimitHeaders (org.mockserver.llm).

Mock creation & matching feedback

• Generalised capture-to-expectation — the dashboard "Capture as Mock" dialog now works for any recorded or proxied request (plain HTTP, gRPC, GraphQL), not just LLM traffic. A three-level matcher precision toggle (Exact / Moderate / Loose) controls how tightly the generated httpRequest matcher binds: from method+path+query+headers+body down to method+path only. Generic captures register via PUT /mockserver/expectation with httpResponse; the existing LLM capture path is unchanged.
• Create expectation from unmatched request — the "Why Didn't This Match?" mismatch diagnostic dialog now includes a "Create Expectation" button that opens the capture-as-mock dialog pre-filled with the unmatched request, letting users turn a near-miss into a working stub in one click.
• Client-visible match feedback — new opt-in config property attachMismatchDiagnosticToResponse (default false) attaches closest-match diagnostic info (header x-mockserver-closest-match + JSON body with per-field diffs) to 404 responses for unmatched requests, so test authors can see why their mock didn't match without checking the dashboard or logs.
• Opt-in realistic OpenAPI example data — new config property generateRealisticExampleValues (default false) makes OpenAPI example generation produce schema/format-aware values via Datafaker (email, UUID, date, date-time, URI, hostname, IPv4/IPv6, byte, password, integers/numbers respecting min/max) instead of static placeholders, with a fixed seed for deterministic output. Existing behaviour is unchanged when the flag is off.

Response templates

• Templates can be loaded from a file — httpResponseTemplate and httpForwardTemplate accept a new templateFile field (a classpath-or-filesystem path) as an alternative to the inline template, keeping large templates out of the expectation JSON. When both are set the inline template takes precedence. Works with all three engines (Velocity, Mustache, JavaScript).
• Templated response body files — a static httpResponse whose body is a FILE body can set a templateType of MUSTACHE or VELOCITY, in which case the file contents are rendered as a template against the request before being returned (the status code, headers and content type still come from the static response). This combines externally stored response bodies (issue #2163) with response templating, as requested in discussion #2350. JavaScript is not supported for body files (its templates return a full response object rather than text) — use httpResponseTemplate for that.
• Client-library support for templateFile and templated FILE bodies — the Node, Python, Go, .NET, Ruby and Rust clients gain templateFile on their template models and templateType on FILE response bodies, so the two features above can be driven from each client (the PHP client, which has no template model, gains a fileBody() helper).
• Velocity templates are parsed once and cached — the Velocity engine previously re-parsed the template string on every render. It now caches the parsed template (via Velocity's native string-resource cache) and reuses it, so a repeatedly rendered template (response templating, forward templating, and especially load-scenario steps that render every iteration) is rendered without re-parsing. Output is unchanged. Measured with JMH (-prof gc): 55–79% faster and 46–74% less allocation per render across simple-to-complex templates, with the biggest wins on complex templates under sustained load.
• Velocity render allocates less per request — the stateless built-in template functions and helpers ($uuid, $faker, $json, etc.) are now shared across renders via a single immutable context layer instead of being copied into a fresh context on every render. Request-scoped state (the request, the per-iteration values, and request-scoped tools like $json/$xml) is still built fresh per render, so output and thread-safety are unchanged. Measured with JMH: a further ~1 KB/op less allocation and 30–67% faster per render on top of the parse-once caching above.

... (truncated)

Commits

• 0920d46 release: publish mockserver-client-node 7.1.0
• dcc33b6 release: update version references to 7.1.0
• e367580 release: set version 7.1.0
• 53ba40a test(client-node): run integration tests against the locally-built server
• 3d36688 feat(clients): response verification across 7 client libraries
• 3d9dfb3 feat(clients): support templateFile and templated FILE bodies across client l...
• 36bdbf3 feat(clients): rename .NET NuGet package to MockServerClient; add opt-in clie...
• 7d76f94 build(deps-dev): bump @​types/node (#2345)
• 2a6bf91 ignore test-results json
• 2dbc230 fix(clients): derive launcher version (Go embed / .NET assembly) + document l...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)