---
title: Fix Scale API HPA Gate Behavior for Manual Scale Requests
updated: 2026-04-24
watches:
  - domain/server/scale_sharedpool.go
  - domain/server/update_tidbgroup.go
  - domain/server/common.go
  - domain/server/scale_sharedpool_test.go
  - domain/server/update_tidbgroup_test.go
---

## Summary

Current manual scale behavior is too strict for HPA-managed components:

- `force=true` still does not bypass the HPA gate.
- Manual scale-in is blocked when HPA scale-up is enabled.

This proposal changes the behavior so that:

- `force=true` skips the HPA checking gate entirely.
- The HPA checking gate only applies to manual scale-out.
- Manual scale-in remains allowed even when HPA scale-up is enabled.

## Problem

The current implementation rejects manual scale requests for HPA-managed components on both directions:

- Scale-out is rejected when HPA scale-down is enabled.
- Scale-in is rejected when HPA scale-up is enabled.

This creates two issues:

- `force` is inconsistent with other protective checks because it does not actually force past the HPA gate.
- Blocking scale-in is unnecessary. When workload is low, a user-initiated scale-in should still be accepted. If workload rises later, HPA scaling back out is expected and reasonable.

## Proposed Behavior

For `ScaleSharedPool` and `ScaleTiDBGroup` node-count changes:

- If `force=true`, skip all HPA gate checks.
- If target node count is greater than current node count, keep the existing HPA scale-out protection.
- If target node count is less than current node count, do not check HPA scale-up state.

This means:

- Manual scale-out still requires disabling the conflicting HPA direction first, unless `force=true`.
- Manual scale-in is accepted even if HPA may later scale the component back out.

## Scope

In scope:

- `domain/server/scale_sharedpool.go`
- `domain/server/update_tidbgroup.go`
- Related tests: `domain/server/scale_sharedpool_test.go`, `domain/server/update_tidbgroup_test.go`

Out of scope:

- Changing which component types are considered HPA-managed.
- Changing `SetHPAScaleBehavior` semantics.
- Fixing the separate inconsistency that `ScaleTiDBGroupRequest.component_type` is currently ignored by the app layer.

## Implementation Outline

- In `ScaleSharedPool`, gate the HPA precheck behind `!force`.
- Keep only the scale-out branch that checks `checkHPAScaleDownDisabled`.
- Remove the scale-in branch that checks HPA scale-up state.
- Apply the same logic in `UpdateTiDBGroup`.
- Remove obsolete helper code once the new tests are in place.

## Test Plan

- Update existing tests to verify `force=true` bypasses the HPA gate for scale-out.
- Update existing tests to verify scale-in is allowed even when HPA scale-up is enabled.
- Keep scale-out rejection tests for non-force requests where HPA scale-down is enabled.
- Confirm unaffected behavior for non-HPA components and for no-op node-count changes.

## Risks

- After a successful manual scale-in, HPA may scale the component back out later if demand rises.

This is acceptable and matches the intended autoscaling model.

## Estimated Change Size

`~40-80 LoC`