ext_proc: ignore send_body_without_waiting_for_header_response in streamed body modes

[Aditya7880900936]

Summary

This PR fixes the interaction between send_body_without_waiting_for_header_response
and streamed body processing modes.

When the body processing mode is STREAMED or FULL_DUPLEX_STREAMED, sending body
frames before receiving the header response is incorrect and can violate the expected
ext_proc protocol flow.

This change ensures that send_body_without_waiting_for_header_response is ignored
for streamed body modes, while preserving existing behavior for buffered modes.

Changes

• Detect streamed body modes (STREAMED, FULL_DUPLEX_STREAMED) via overridable body mode
• Prevent early body streaming when send_body_without_waiting_for_header_response is set
• Keep behavior unchanged for buffered body processing modes

Testing

• Existing ext_proc unit and integration tests pass
• Streamed and full-duplex streaming test cases validate correct behavior

Fixes #149

[kmesh-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign dawid-nowak for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[kmesh-bot]

Welcome @Aditya7880900936! It looks like this is your first PR to kmesh-net/orion 🎉

[gemini-code-assist]

Summary of Changes

Hello @Aditya7880900936, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request resolves an interaction issue within the ext_proc module where the send_body_without_waiting_for_header_response flag could lead to incorrect protocol behavior when body processing was set to streamed modes. The changes ensure that early body streaming is disabled for STREAMED and FULL_DUPLEX_STREAMED configurations, aligning with the expected ext_proc protocol while preserving existing functionality for buffered body modes. This prevents potential issues arising from sending body frames before the header response in these specific streaming scenarios.

Highlights

• Protocol Compliance: Ensures the ext_proc protocol flow is correctly followed by preventing early body streaming in STREAMED and FULL_DUPLEX_STREAMED modes, which previously could violate expected behavior.
• Conditional Behavior: The send_body_without_waiting_for_header_response flag is now conditionally applied, being ignored for streamed body modes while maintaining its original behavior for buffered modes.
• New Helper Function: Introduced a new private helper function is_streamed_body_mode to cleanly identify Streamed or FullDuplexStreamed body processing types.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request correctly addresses an issue where send_body_without_waiting_for_header_response was being incorrectly applied to streamed body modes, which could violate the ext_proc protocol. The change ensures this optimization is only active for buffered modes, aligning with the expected behavior. The logic is sound and the fix is well-targeted. I have one suggestion to improve the readability of the new conditional logic.

[Copilot]

Pull request overview

This PR fixes a protocol flow issue where send_body_without_waiting_for_header_response was incorrectly applied to streamed body processing modes (STREAMED and FULL_DUPLEX_STREAMED), which could violate the expected ext_proc protocol flow.

Key Changes:

• Introduced a helper function to detect streamed body modes
• Modified the condition for enabling early body streaming to exclude streamed modes
• Preserved existing behavior for buffered body processing modes (Buffered, BufferedPartial)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

While the existing tests cover send_body_without_waiting_for_header_response for buffered modes and streamed modes separately, there's no test coverage for the new behavior that ensures send_body_without_waiting_for_header_response is ignored when using streamed body modes (STREAMED or FULL_DUPLEX_STREAMED). Consider adding test cases that verify this interaction to ensure the fix works as intended and to prevent regressions.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dawid-nowak]

See my other comment...

[Aditya7880900936]

Hi @dawid-nowak ,
I implemented your requested changes kindly check it out and please let me know if there any further changes needed ,
Regards

[dawid-nowak]

Still not sure if this is going to work as expected.. see my other comment

[dawid-nowak]

i am still not sure if this is going to work as expected,
my understanding is streaming_body_enabled should be true unless self.send_body_without_waiting_for_header_response is false and OverridableBodyMode::Streamed
in every other case we assume that we will send the body without waiting for the response

[Aditya7880900936]

Hi @dawid-nowak, thanks for the clarification — that makes sense.

You’re right, according to the Envoy documentation the
send_body_without_waiting_for_header_response flag is only meaningful
for STREAMED mode and ignored for other body modes.

Based on your comment, the correct behavior should be:

• streaming_body_enabled defaults to true
• except when:
  • body_mode == OverridableBodyMode::Streamed
  • AND send_body_without_waiting_for_header_response == false
    In that specific case we should wait for the header response before
    sending body frames.

I’ll update the logic accordingly and adjust the condition so that
non-streamed modes always send the body early, matching Envoy semantics.

Thanks for pointing this out — I’ll push an updated commit shortly.