Skip to content

fix(vmcp): honor configured backend request timeouts - #2

Merged
MatteoManzoni merged 1 commit into
dp-stablefrom
fix/configurable-vmcp-backend-timeouts
Jul 22, 2026
Merged

MatteoManzoni merged 1 commit into
dp-stablefrom
fix/configurable-vmcp-backend-timeouts

Conversation

@MatteoManzoni

Copy link
Copy Markdown

No description provided.

@MatteoManzoni
MatteoManzoni merged commit b2b6c3e into dp-stable Jul 22, 2026
6 of 14 checks passed
@carlos-lopez-vecino
carlos-lopez-vecino deleted the fix/configurable-vmcp-backend-timeouts branch September 28, 2026 09:49
carlos-lopez-vecino pushed a commit that referenced this pull request Oct 8, 2026
…k#5563)

* Wire MCPAuthzConfig references into the MCPServer controller

An MCPServer that sets spec.authzConfigRef now resolves and enforces the
referenced MCPAuthzConfig at runtime, mirroring the OIDCConfigRef pattern and
building on the Stage-1 controllerutil helpers. Backend-agnostic: the proxy
runner's authz factory handles cedarv1 and httpv1 alike.

- handleAuthzConfig: fetch + validate-ready, track AuthzConfigHash, set the
  AuthzConfigRefValidated condition; on nil-ref it clears the hash AND removes
  the condition so a stale "valid" signal does not linger (unlike the OIDC
  version). Wired into Reconcile after handleOIDCConfig.
- mapAuthzConfigToServers watch (extracted as a named method) + Watches on
  MCPAuthzConfig so a config change re-reconciles referencing servers.
- Runtime resolution via AddAuthzConfigRefOptions in the runconfig builder;
  ConfigMap materialization via EnsureAuthzConfigMapFromRef and a mounted volume
  via GenerateAuthzVolumeConfigFromRef. Inline spec.authzConfig is untouched and
  remains mutually exclusive (CRD XValidation).
- Add the mcpauthzconfigs get;list;watch RBAC marker.
- Unit tests for handleAuthzConfig and an envtest integration suite proving both
  backends, the watch re-reconcile, ConfigMap materialization, and the invalid
  case.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Guard ref authz volume against duplicate volume name

Belt-and-suspenders for review feedback: only add the spec.authzConfigRef
volume when the inline authz volume was not added. Inline and ref share the
"authz-config" volume name and are mutually exclusive via CRD XValidation, so a
hypothetical CEL regression now degrades to "inline wins" rather than producing
an invalid pod spec with a duplicate volume name.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* Address review feedback on MCPServer authz wiring

- Document fail-stale-on-revocation semantics on handleAuthzConfig: a
  previously-valid ref that later becomes invalid/missing leaves an already-
  running workload enforcing its last-applied policy (fail-stale, not fail-open)
  while the MCPServer is marked Failed/Ready=False. (#2)
- Note on GenerateAuthzVolumeConfigFromRef that the mounted ConfigMap is not the
  active enforcement path in operator deployments (the proxy reads authz from the
  RunConfig-embedded config); the mount is for inline parity / future file-based
  consumption. (#3)
- Reword the status-write error messages to name the MCPServer (the object being
  written), not the MCPAuthzConfig. (#4)
- Add a transition unit test (valid -> invalid -> valid) covering the needsUpdate
  bookkeeping, plus an integration It asserting the valid -> invalid flip
  propagates to the MCPServer via the watch. (#1)
- Soften the watch test's "via the watch" phrasing to claim only the observable
  outcome. (#5)
- Tighten the unit not-found/not-valid assertions with ErrorContains. (#6)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant