api: validate labels in store-limit requests

[JmPotato]

What problem does this PR solve?

Issue Number: Close #11234

Malformed labels in POST /pd/api/v1/stores/limit, such as {"rate":25,"type":"add-peer","labels":null}, trigger unchecked type assertions and return HTTP 500 with a panic stack.

What is changed and how does it work?

Validate that labels is an object containing string values before updating
store limits. Return HTTP 400 for malformed input while preserving valid
label filtering and existing store and default limits on rejection.

Check List

Tests

• Unit test: make basic-test BASIC_TEST_PKGS=github.com/tikv/pd/server/api
• Integration test: Store API suite with race/deadlock in Classic and NextGen builds, covering monolithic PD and microservices.
• Manual test: Removing the object check or the value check independently restores HTTP 500 and fails the corresponding regression cases.
• make check

Code changes

• Has HTTP APIs changed: malformed labels now return HTTP 400.

Related changes

• Need to cherry-pick to affected release branches.

Release note

Fix a panic caused by malformed labels in store-limit HTTP requests.

Summary by CodeRabbit

• Bug Fixes

  • Invalid store limit label selectors now return a clear 400 Bad Request response instead of causing an error.
  • Valid empty or nonmatching selectors remain safe no-ops.
  • Matching label selectors correctly apply the configured store limit.

• Tests

  • Added coverage for valid, invalid, empty, and nonmatching label selectors.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Advanced

Run ID: bc0b663d-2381-477b-91e1-76b0ac6d7b11

📥 Commits

Reviewing files that changed from the base of the PR and between addfeb0 and af78f9e.

📒 Files selected for processing (2)

• server/api/store.go
• tests/server/api/store_test.go

Included review availability: Your plan provides up to 4 included reviews per hour; 3 remain after this review.

---

📝 Walkthrough

Walkthrough

The store-limit API now returns HTTP 400 for malformed label selectors instead of panicking. Tests cover invalid selector shapes, unchanged configuration after rejection, no-op selectors, and matching selectors across supported limit types.

Changes

Store limit label handling

Layer / File(s)	Summary
Label validation server/api/store.go	SetAllStoresLimit validates that labels is an object and that each label value is a string before applying limits.
Validation and update tests tests/server/api/store_test.go	Tests verify HTTP 400 responses and unchanged configuration for malformed selectors, successful no-ops for empty or nonmatching selectors, and updates for matching selectors across limit types.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to af78f

Malformed label requests now return HTTP 400 without changing store-limit configuration, and valid label-filtered updates retain their expected behavior.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description explains the problem, identifies the issue, describes the implementation, lists tests, notes the HTTP API behavior, identifies release-branch cherry-picking, and includes a release not…
Title check	✅ Passed	The title clearly identifies the API scope and the primary change: validating labels in store-limit requests.
Linked Issues check	✅ Passed	The implementation for issue #11234 validates labels before applying updates. It returns HTTP 400 when labels is not an object or when a label value is not a string. The test covers add-peer, `r…
Out of Scope Changes check	✅ Passed	The changes are limited to label validation in SetAllStoresLimit and regression tests for the store-limit API. Both changes directly support issue #11234. No unrelated production behavior or unrelat…
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 2…

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[ti-chi-bot]

@coderabbitai[bot]: adding LGTM is restricted to approvers and reviewers in OWNERS files.

Details

In response to this:

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: coderabbitai[bot]
Once this PR has been reviewed and has the lgtm label, please assign cabinfeverb for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

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

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.80%. Comparing base (2d43fe9) to head (af78f9e).
⚠️ Report is 6 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #11235      +/-   ##
==========================================
+ Coverage   79.79%   79.80%   +0.01%     
==========================================
  Files         544      545       +1     
  Lines       78879    78898      +19     
==========================================
+ Hits        62942    62967      +25     
- Misses      11570    11572       +2     
+ Partials     4367     4359       -8     

Flag	Coverage Δ
unittests	79.80% <100.00%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.