feat(worker): add max_running_requests accessor on Worker trait

[slin1237]

Summary

• Adds a max_running_requests(&self) -> Option<u16> default method on the Worker trait that reads the max_running_requests label populated by metadata discovery (vLLM --max-num-seqs, SGLang --max-running-requests).
• Returns None when the label is missing, unparseable, or zero (zero is meaningless for capacity accounting).
• Pure addition — no callers yet. Sets up the input that an upcoming WorkerCapacity component will consume to derive fleet-wide in-flight capacity from WorkerRegistry.

Test plan

• cargo test --package smg --lib worker::worker::tests::test_max_running_requests — 4 new tests pass (label present / missing / unparseable / zero).
• cargo clippy --all-targets --all-features -- -D warnings — clean.
• No regression in existing worker::* tests.

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features

  • Workers can now surface a configured maximum concurrent-request limit via metadata labels; the limit is returned as an optional numeric value when specified and treated as unspecified for missing, invalid, or "0" labels.

• Tests

  • Added unit tests validating a valid numeric limit, missing label, non-numeric label, and "0" treated as unspecified to ensure predictable behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: 916f35f2-87d8-4c6f-bef5-39ec3de8297d

📥 Commits

Reviewing files that changed from the base of the PR and between c15b1a1 and 8247eee.

📒 Files selected for processing (1)

• model_gateway/src/worker/worker.rs

---

📝 Walkthrough

Walkthrough

Adds a default Worker::max_running_requests() that reads "max_running_requests" from WorkerMetadata.spec.labels, parses it as u16, and returns None for missing, non-numeric, or zero values. Unit tests cover valid, missing, non-numeric, and "0" cases.

Changes

Worker max_running_requests capacity

Layer / File(s)	Summary
max_running_requests method implementation model_gateway/src/worker/worker.rs	Worker trait gains a default max_running_requests() method reading from WorkerMetadata.spec.labels["max_running_requests"], parsing as u16, and returning None for missing, invalid, or zero-valued labels.
max_running_requests parsing tests model_gateway/src/worker/worker.rs	Four test cases validate the parsing logic: valid numeric label returns Some(u16), missing label returns None, non-numeric value returns None, and zero value returns None.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• CatherineSue
• claude

Poem

🐰 I nibble labels in the night,
Counting limits out of sight,
Dig for digits, toss the rest,
Zero sleeps — it's not the best.
Tests hop by and give their light.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'feat(worker): add max_running_requests accessor on Worker trait' directly and clearly describes the main change—adding a new method to the Worker trait.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ 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 feat/worker-max-running-requests

---

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

[mergify]

Hi @slin1237, the DCO sign-off check has failed. All commits must include a Signed-off-by line.

To fix existing commits:

# Sign off the last N commits (replace N with the number of unsigned commits)
git rebase HEAD~N --signoff
git push --force-with-lease

To sign off future commits automatically:

• Use git commit -s every time, or
• VSCode: enable Git: Always Sign Off in Settings
• PyCharm: enable Sign-off commit in the Commit tool window

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2915272894

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Parse max_running_requests with full int32 range

This parser uses u16, but the upstream scheduler schemas expose max_running_requests as int32 (for example in crates/protocols/src/worker.rs), so any valid value above 65,535 will be treated as parse failure and silently converted to None. In deployments that set very high concurrency limits, this drops real capacity data and forces downstream logic to fall back as if the worker never reported a limit.

Useful? React with 👍 / 👎.

[gemini-code-assist]

Code Review

This pull request introduces the max_running_requests method to the Worker trait, enabling the gateway to derive worker capacity from metadata labels, and includes comprehensive unit tests for this new functionality. The reviewer suggested enhancing the robustness of the label parsing by adding a .trim() call to handle potential whitespace and reminded the author to ensure the metadata discovery pipeline is updated to populate these fields.

[gemini-code-assist]

Instead of widening the return type to usize, maintain the more restrictive internal protocol type (e.g., u16) when mapping from external sources like labels. This aligns with the repository's preference for safe conversions over changing internal protocols, especially when the backend might not support wider types. Additionally, use .trim() before parsing to make the accessor more resilient to accidental whitespace in labels.

Note: To fulfill the intent of being "populated by metadata discovery", ensure that the discovery pipeline (e.g., the ServerInfo and ModelsResponseEntry structs in discover_metadata.rs) is updated to include these fields so they can be captured into labels.

Suggested change

	fn max_running_requests(&self) -> Option<u16> {
	self.metadata()
	.spec
	.labels
	.get("max_running_requests")
	.and_then(|s| s.parse::<u16>().ok())
	.filter(|n| *n > 0)
	}
	fn max_running_requests(&self) -> Option<u16> {
	self.metadata()
	.spec
	.labels
	.get("max_running_requests")
	.and_then(|s| s.trim().parse::<u16>().ok())
	.filter(|n| *n > 0)
	}

References

1. When mapping a numeric type from an external API to a more restrictive internal protocol type, prefer a safe conversion that drops out-of-range values over changing the internal protocol.

[claude]

Clean addition. The accessor is well-documented, well-tested, and the zero-filtering behavior is a sensible design choice. The u16 range question raised by another reviewer is worth considering but not blocking — 65,535 concurrent requests per worker is well beyond realistic capacity.