chore(toolhive): 0.42.0 → 0.42.1 for the slow-backend session fix

[blarghmatey]

What are the relevant tickets?

No GitHub issue — tracked in witan's task graph under wp-witan-multi-user-service-deployment-dcf6ee. Upstream: stacklok/toolhive#5861 (report) and #6162 (fix).

Description (What does it do?)

Bumps TOOLHIVE_OPERATOR_CHART_VERSION and TOOLHIVE_OPERATOR_CRDS_CHART_VERSION from 0.42.0 to 0.42.1.

Why now. In v0.42.0 a backend that is merely slow — not down, not erroring — could drag its entire vMCP tenant's client-facing initialize success rate to roughly a coin flip, with no self-healing. Health status gated capability aggregation but never connection establishment, which runs first: the new-session backend list was the registry unfiltered, makeBaseSession blocks on every backend it attempts, and the circuit breaker's CanAttempt() had exactly one production caller — the monitor's own background loop. Every new session re-attempted a backend the monitor already knew was bad, and re-paid close to the full timeout.

witan is that backend under load. Measured 2026-08-13 against CI during a 24-writer burst, single memory_store handlers ran 3–36s, median 15s. The upstream fix quantifies the cost:

the handshake makes several sequential round trips, each paying full latency. The regression test measures 8s of session-creation delay from a 2s backend — 4× amplification

That is the leading candidate for a gap we could not previously explain: 13 client-side failures against only 3 handlers that ran past 30s. Each concurrency-probe worker is a separate process opening a fresh session, so it pays amplified session establishment before its tool call — invisible both to witan's own duration_ms metric and to its client-side write gate. The fix merged 2026-08-07, two days after v0.42.0 was cut, so we do not have it.

The three breaking changes, each checked against the live cluster

v0.42.1 is a security-hardening release. All three breaking changes were verified as non-applicable before bumping — the third is the one that mattered:

1. Non-JSON POSTs rejected when Cedar authorization is enabled — does not apply. spec.authzConfig is null on our VirtualMCPServer; ToolHive's Cedar authz is not enabled. (witan's Cedar policies live in omnigraph, a different enforcement point entirely, untouched by this.)

2. vMCP tools hidden from tools/list are no longer directly callable — does not apply. Our aggregation config sets only conflictResolution: priority with a priorityOrder; there is no filter, excludeAll or excludeAllTools anywhere.

3. MCPOIDCConfig inline issuer/JWKS URL validation — does not apply, and this is the one that could have hurt: a malformed or plain-HTTP URL flips the config to Valid=False and blocks reconciliation of every workload referencing it. Both inline configs carry HTTPS issuers, no inline JWKS URL, and insecureAllowHTTP: false:

   namespace/name	issuer
   witan/witan-vmcp-oidc	https://sso-ci.ol.mit.edu/realms/ol-platform-engineering
   toolhive-swe/swe-vmcp-oidc	https://toolhive-swe.ci.ol.mit.edu

⚠️ Blast radius

The operator injects toolhiveRunnerImage and vmcpImage into child workloads at runtime via env vars (TOOLHIVE_RUNNER_IMAGE / VMCP_IMAGE) rather than rendering them as chart image: keys. So this rolls proxyrunner and vmcp to v0.42.1 for every ToolHive workload in the environment — toolhive-swe as well as witan, not just the one that motivated it. Expect both tenants' MCP pods to restart on reconcile.

How has this been tested?

pulumi preview against CI:

~ kubernetes:helm.sh/v3:Release toolhive-operator-crds-ci-helm-release  update [diff: ~version]
~ kubernetes:helm.sh/v3:Release toolhive-operator-ci-helm-release       update [diff: ~version]

Resources: ~ 2 to update, 2 unchanged

Both charts confirmed to exist at 0.42.1 (helm show chart oci://ghcr.io/stacklok/toolhive/...), each with matching appVersion: 0.42.1. pre-commit over the diff: ruff, ruff format and mypy pass.

Not yet applied. This has not been observed against a running cluster — the claim that it explains the session-establishment gap is a hypothesis from the upstream regression test, and wants a re-run of the concurrency probe after deploy to confirm.

Does this change require a change to documentation?

No.

[Copilot]

Pull request overview

Bumps ToolHive operator and CRD charts to v0.42.1, incorporating the upstream slow-backend session fix and security hardening.

Changes:

• Updates both ToolHive chart versions from 0.42.0 to 0.42.1.
• Rolls v0.42.1 workloads across all ToolHive tenants during reconciliation.

---

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