vllm-project / vllm-project/agentic-api

code clean up / refactor

Open
#312 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

good first issue
Dominant language
Rust
Stars
284
Forks
74
Avg merge
1d 17h
Merged PRs (30d)
93

Description

Summary

Several Rust files are large enough to make review and maintenance difficult, consistent with feedback from maintainers. Track a focused cleanup into cohesive modules with clear ownership and smaller review surfaces.

Proposed file-size policy
  • Prefer production files under 300 lines; 300–500 lines is reasonable for one clear responsibility.
  • Require a split or a documented exception above 500 production lines.
  • Prevent new oversized production files and growth of existing oversized files through a fast pre-commit/CI check with an explicit baseline.
  • Count inline tests separately and exclude generated code. Choose a separate test-file threshold before enforcing one.
  • Split by responsibility, not arbitrary line counts. Preserve public APIs, wire formats, behavior, and test coverage.

Production refactor checklist

Inventory at commit 6d038d12da167255861a71d22681930dd46f904b. Counts include comments and blank lines. Approximate production counts use the lines before the first top-level #[cfg(test)] mod tests section; these are triage measurements, not an AST-based enforcement implementation. Recount and confirm module boundaries when taking each item.

Entries are ordered by approximate production size; each should be refactored or given a documented cohesion-based exception.

Start with these boundaries
  • tool/tool_search.rs: separate request validation, loaded-definition/catalog state, and tool-call translation.
  • types/io/output.rs: group output-item types and conversions by item family, preserving the public exports and wire schema.
  • handler/websocket/responses.rs: review request parsing, admission/multiplexing, connection lifecycle, and outbound delivery boundaries.
  • executor/engine.rs: keep round orchestration, tool-loop control, and persistence ownership explicit; move responsibilities only to their architecture-defined owners.
  • auth.rs: review configuration, provider/JWKS fetching and caching, token verification, and HTTP middleware boundaries.

These are starting points for review, not predetermined module designs.

Large test and benchmark files — separate cleanup

The following files exceed 800 total lines and deserve a scenario-based organization review. This is a triage cutoff, not a proposed test-file enforcement limit. Preserve coverage and share fixtures only where that improves readability.

Completion criteria

  • Work through the production checklist in small, behavior-preserving PRs; document justified exceptions.
  • Organize oversized test suites by behavior/scenario without reducing coverage.
  • Implement and document the agreed file-size check, counting test-only code separately and baselining existing oversized files.
  • Preserve the ownership boundaries in ARCHITECTURE.md and vocabulary in TERMINOLOGY.md.
  • Coordinate executor/streaming changes with #241, #243, #244, and #245. Keep a single ingestion path and typed extension points; do not introduce duplicate lifecycle validators, assemblers, or client-emission paths just to shorten files.
  • For each refactor, run relevant tests, cargo fmt -- --check, cargo clippy --all-targets -- -D warnings, and required pre-commit hooks. Preserve lifecycle, cancellation, backpressure, and disconnect coverage for affected streaming boundaries.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading ARCHITECTURE.md and TERMINOLOGY.md, then choose one listed production file such as crates/agentic-server-core/src/tool/tool_search.rs and review its proposed responsibility boundaries. Run the relevant crate tests before changing anything. Done means a behavior-preserving, separately reviewable refactor with coverage intact, formatting and clippy passing, and any justified exception documented.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, backend, tooling
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.