refactor(grpc): rename shared dispatcher stages, remove dead arms

[CatherineSue]

Description

Problem

The three shared dispatcher stages (PreparationStage, RequestBuildingStage, ResponseProcessingStage) have misleading generic names and contain dead match arms for request types that never reach them.

These dispatchers are only used by new_regular() and new_pd() pipelines, which exclusively serve Chat + Generate requests. All other endpoints have dedicated pipelines that wire their own stages directly:

Endpoint	Pipeline	Wires stages directly?
Chat	new_regular() / new_pd()	No — goes through dispatchers
Generate	new_regular() / new_pd()	No — goes through dispatchers
Embedding	new_embeddings()	Yes
Classify	new_classify()	Yes
Messages	new_messages()	Yes
Completion	new_completion()	Yes

Solution

Rename dispatchers to reflect their actual scope and remove dead arms:

• PreparationStage → ChatGeneratePreparationStage — remove Completion arm + field
• RequestBuildingStage → ChatGenerateRequestBuildingStage — remove Embedding/Classify arms + field
• ResponseProcessingStage → ChatGenerateResponseProcessingStage — remove Embedding/Classify arms + fields

Changes

• Rename and simplify 3 dispatcher stage files
• Update mod.rs re-exports
• Update pipeline.rs to use new names

Test Plan

• cargo check passes
• cargo clippy --all-targets --all-features -- -D warnings passes
• cargo +nightly fmt passes

Checklist

• cargo +nightly fmt passes
• cargo clippy --all-targets --all-features -- -D warnings passes

Summary by CodeRabbit

• Refactor
  • gRPC request pipeline reorganized to focus on Chat and Generate request types, replacing generic stages with chat/generate-specific stages.
  • Removed handling for Embedding and Classify flows in those stages; non-chat/generate requests now hit a single fallback path with clearer error logging.
  • Stage names and stage composition updated for clearer routing and maintenance.

[coderabbitai]

📝 Walkthrough

Walkthrough

The regular gRPC request pipeline stages were specialized: generic Preparation/RequestBuilding/ResponseProcessing stages were replaced with chat/generate-specific variants, and stage dispatch was narrowed to handle only Chat and Generate request types (Embedding and Classify handling removed).

Changes

Cohort / File(s)	Summary
Pipeline wiring model_gateway/src/routers/grpc/pipeline.rs	Replaced generic stage types with ChatGenerate* stage instances in both new_regular and new_pd pipeline construction paths, preserving PD metadata flags and existing processor wiring.
Module exports model_gateway/src/routers/grpc/regular/stages/mod.rs	Re-exported chat/generate-specific stage types: ChatGeneratePreparationStage, ChatGenerateRequestBuildingStage, ChatGenerateResponseProcessingStage instead of the previous generic aliases.
Preparation stage model_gateway/src/routers/grpc/regular/stages/preparation.rs	Renamed PreparationStage → ChatGeneratePreparationStage; removed Completion branch/field; execute() now matches only Chat and Generate request types; updated stage name and error logging.
Request building stage model_gateway/src/routers/grpc/regular/stages/request_building.rs	Renamed RequestBuildingStage → ChatGenerateRequestBuildingStage; removed Embedding/Classify handling and other special-case arms; execute() now dispatches only Chat and Generate; adjusted logging and name.
Response processing stage model_gateway/src/routers/grpc/regular/stages/response_processing.rs	Renamed ResponseProcessingStage → ChatGenerateResponseProcessingStage; removed embedding/classify fields and match arms; execute() now routes Chat and Generate only; updated logging and name.

Sequence Diagram(s)

(omitted)

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• feat(completions): add CompletionPreparationStage for gRPC pipeline #907: Modifies the same preparation-stage area by adding CompletionPreparationStage and routing Completion requests, which directly intersects with the removal of Completion handling here.
• feat(gateway): add Messages API type scaffolding to gRPC router #739: Changes request_building and response_processing dispatch logic for RequestType variants; overlaps with the narrowed Chat/Generate dispatch in this change.
• feat(gateway): add message_utils and MessagePreparationStage for Messages API #741: Touches the preparation stage and its request-type delegation behavior, making it closely related to these refactors.

Suggested reviewers

• key4ng
• slin1237

Poem

🐰 A hop, a tweak, the stages realigned,
Chat and Generate now walk the line.
No more detours for embed or class,
The pipeline's nimble—quick as a pass. ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 16.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main changes: renaming three dispatcher stages (PreparationStage, RequestBuildingStage, ResponseProcessingStage to their ChatGenerate variants) and removing dead match arms for unreachable request types.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch changsu/investigate-request-building-stage

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[gemini-code-assist]

Code Review

This pull request refactors the gRPC request pipeline by renaming generic stages to ChatGenerate specific implementations, such as ChatGeneratePreparationStage, ChatGenerateRequestBuildingStage, and ChatGenerateResponseProcessingStage. The changes also involve narrowing the scope of these stages by removing logic for handling unrelated request types like Completion, Embedding, and Classify, focusing them exclusively on Chat and Generate requests. I have no feedback to provide.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@model_gateway/src/routers/grpc/regular/stages/request_building.rs`:
- Around line 18-20: The doc comment in request_building.rs incorrectly
references the removed constructor `new_regular_pd`; update that reference to
the current PD constructor `new_pd()` so readers are pointed to the actual
symbol (keep the other reference `new_regular` as-is), i.e., change the doc line
mentioning `new_regular_pd` to `new_pd()` to match the constructor defined in
the pipeline module.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: ef40323a-904b-4f46-ae55-81d7c1609375

📥 Commits

Reviewing files that changed from the base of the PR and between a484b61 and b19f5c7.

📒 Files selected for processing (5)

• model_gateway/src/routers/grpc/pipeline.rs
• model_gateway/src/routers/grpc/regular/stages/mod.rs
• model_gateway/src/routers/grpc/regular/stages/preparation.rs
• model_gateway/src/routers/grpc/regular/stages/request_building.rs
• model_gateway/src/routers/grpc/regular/stages/response_processing.rs

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@model_gateway/src/routers/grpc/regular/stages/request_building.rs`:
- Around line 55-57: The stage name returned by fn name(&self) -> &'static str
in the ChatGenerateRequestBuilding stage was changed to
"ChatGenerateRequestBuilding", so update any log-based filters, dashboards, and
alert rules that previously matched the old "RequestBuilding" label to now match
"ChatGenerateRequestBuilding"; verify any usages in pipeline.rs and related
alerting/aggregation configurations that rely on stage labels and adjust them
accordingly to avoid missing logs or false alerts.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: e2ff8e81-45dd-40a7-8506-ba9a582337c9

📥 Commits

Reviewing files that changed from the base of the PR and between b19f5c7 and cd8977a.

📒 Files selected for processing (1)

• model_gateway/src/routers/grpc/regular/stages/request_building.rs

[coderabbitai]

🧹 Nitpick | 🔵 Trivial

Stage name change affects log labels — update any log-based alerts if needed.

The stage name returned by name() is used throughout pipeline.rs for error and debug logging (as shown in the relevant code snippets). Any log aggregation, dashboards, or alerts filtering on the old "RequestBuilding" label will need to be updated to "ChatGenerateRequestBuilding".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@model_gateway/src/routers/grpc/regular/stages/request_building.rs` around
lines 55 - 57, The stage name returned by fn name(&self) -> &'static str in the
ChatGenerateRequestBuilding stage was changed to "ChatGenerateRequestBuilding",
so update any log-based filters, dashboards, and alert rules that previously
matched the old "RequestBuilding" label to now match
"ChatGenerateRequestBuilding"; verify any usages in pipeline.rs and related
alerting/aggregation configurations that rely on stage labels and adjust them
accordingly to avoid missing logs or false alerts.