[Automated] Draft docs (agentgateway): ext proc: handle fail open with body

[github-actions]

Draft a documentation change

agentgateway/agentgateway#3542 — ext proc: handle fail open with body

• Product: agentgateway (upstream) → agentgateway/website
• Docs version: standalone/main, kubernetes/main
• Code issue: InferencePool failureMode with FailOpen not work agentgateway#3473
• Summary (read from the body): ext proc: handle fail open with body
• Not tested: no cluster was available, so every command in this diff is unrun

Warnings

• ext proc: handle fail open with body agentgateway#3542: re-drafting because it was named on this run, though its earlier draft is issue. Nothing removes the earlier entry; the new draft replaces it in the ledger when it opens.

agentgateway/agentgateway#3542 - ext proc: handle fail open with body

• Product: agentgateway (upstream) -> agentgateway/website
• Docs version: standalone/main and kubernetes/main, documented in the development tree

agentgateway/agentgateway#3542 fixes ExtProc fail-open handling when the processor connection fails before streamed request-body processing starts. Requests that use fullDuplexStreamed or FullDuplexStreamed body processing now keep the original body and continue to the backend or upstream application under failOpen or FailOpen. failClosed and FailClosed still return an error. No new configuration field is added; the documented knobs are the existing failure mode and request body mode settings.

How agentgateway-3542 was drafted, and what was not verified

agentgateway/agentgateway#3542 - ext proc: handle fail open with body

• Code PR: ext proc: handle fail open with body agentgateway#3542
• Code issue: InferencePool failureMode with FailOpen not work agentgateway#3473
• Product: agentgateway (upstream) -> agentgateway/website
• Docs version: standalone/main and kubernetes/main, documented in the development tree
• Category: scoped-edit / pr

Plan, and what changed it

• Planned: Clarify ExtProc failure-mode behavior on the standalone and Kubernetes ExtProc pages named by the work-list.
• Learned: diff.patch adds a test for an unavailable external processor with full-duplex streamed request bodies, where fail-open preserves the original body and fail-closed returns HTTP 500.
• Did: Added behavior notes and stable anchors to both ExtProc pages; wrote a proposed release note because observable runtime behavior changed.

Why a documentation change is necessary

The pull request changes what happens when an ExtProc connection fails before request-body streaming starts. Both target pages already document ExtProc failure modes and streamed body processing, but neither page said whether fail-open preserves the original request body in that setup-failure case. A reader configuring fail-open for availability would not know that the backend or upstream application receives the intact body.

What changed on disk

• content/docs/standalone/main/documentation/configuration/traffic-management/extproc.md: Added an explicit failure-modes anchor and documented fail-open body preservation for extProc.processingOptions.requestBodyMode: fullDuplexStreamed.
• content/docs/kubernetes/main/documentation/traffic-management/extproc.md: Added an explicit extproc-server-considerations anchor and documented fail-open body preservation for traffic.extProc.processingOptions.requestBodyMode: FullDuplexStreamed.
  The item has no feature, breaking_change, or deprecation kind, so automatic placement does not choose a release-note section.

How to verify this change

1. Configure ExtProc with an unavailable processor, fail-open mode, and streamed request body processing. In standalone, use host: "127.0.0.1:0", failureMode: failOpen, and processingOptions.requestBodyMode: fullDuplexStreamed. In Kubernetes, use an unavailable traffic.extProc.backendRef, traffic.extProc.failureMode: FailOpen, and traffic.extProc.processingOptions.requestBodyMode: FullDuplexStreamed.
2. Send a POST request with a non-empty body through the route. The response from the backend or upstream application should show the same request body that the client sent.
3. Change the failure mode to failClosed or FailClosed and send the same request again. The request should fail instead of reaching the backend or upstream application.

Proposed release note

The item has no placement kind, so a reviewer must decide whether and where to place the note.

What was not verified

The configuration was not applied to a cluster or standalone gateway, so every command and behavior check in this report is unrun. The proposed release note was not placed automatically because the item has no release-note kind that place_release_notes.py can map to a section.

Draft branch: pr-tracker-draft-agentgateway-3542

---

Important

The test suite has not run on this pull request. It was opened by github-actions[bot], and GitHub does not start workflows for pull requests opened with the repository's own token. Doc tests, link checking and the static checks are held as action_required until somebody presses Approve and run on the Checks tab. Cloudflare Pages and DCO are GitHub Apps rather than Actions, so those two do run on their own.

Please approve the checks before reviewing the content: an absence of failures here means the tests have not run, not that they passed.

[cloudflare-workers-and-pages]

Deploying agentproxy with    Cloudflare Pages

Latest commit:	4f618a2
Status:	⚡️  Build in progress...

View logs