[Autoscaler] Handle deleted node types in metrics reporter

[Kevin-Li-2025]

Summary

Fixes autoscaler v2 metrics reporting when historical instance records reference a worker group that has already been removed from the current node type config.

The reporter now:

• keeps reporting instance gauges for historical node types, so deleted node type labels can be driven back to zero instead of staying stale
• avoids using missing node type configs when computing resource gauges
• adds a regression test for deleted node type records

Fixes #64177.

Validation

• python3 -m py_compile python/ray/autoscaler/v2/metrics_reporter.py python/ray/autoscaler/v2/tests/test_metrics_reporter.py
• isolated importlib/stub verification of deleted node type metrics behavior

pytest -q python/ray/autoscaler/v2/tests/test_metrics_reporter.py is blocked in this local source checkout because Ray is not built and ray._raylet is unavailable.

[gemini-code-assist]

Code Review

This pull request refactors the metrics reporter to safely handle deleted node types by skipping them during resource aggregation and dynamically initializing status counts for unexpected instance types. It also moves a test helper to the module level and adds a unit test for this scenario. The review feedback highlights a performance concern in report_instances where using dict.setdefault causes redundant dictionary allocations on every iteration, suggesting a more efficient lookup pattern instead.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Using dict.setdefault(key, default) always evaluates the default argument (calling _new_status_count() and allocating a new dictionary) on every iteration of the loop, even if the key already exists in the dictionary. For a large number of instances, this results in unnecessary overhead and garbage collection pressure.

Instead, you can check if the key is present first, or use dict.get() to avoid redundant dictionary allocations.

Suggested change

	status_count = status_count_by_type.setdefault(
	instance.instance_type, _new_status_count()
	)
	status_count = status_count_by_type.get(instance.instance_type)
	if status_count is None:
	status_count = _new_status_count()
	status_count_by_type[instance.instance_type] = status_count

[Kevin-Li-2025]

Addressed the review feedback in 6743ebc: replaced setdefault(..., _new_status_count()) with a lazy get/insert path, so configured node types no longer allocate a throwaway status dictionary for every instance while preserving support for deleted node types. Validation: git diff --check, py_compile, and Ruff check/format all pass. The focused pytest file cannot import in this source-only checkout because ray._raylet is not built.

[Kevin-Li-2025]

I checked the failing buildkite/microcheck status. The failed step is :database: data: arrow v23 tests [g7_s11], running the Ray Data/AIR test matrix (//python/ray/data/... //python/ray/air/...) rather than the autoscaler metrics reporter path changed in this PR. I cannot see a PR-specific failure trace from the public status page; could a maintainer rerun microcheck or share the failed log if there is an actionable failure here?

[Kevin-Li-2025]

I checked the new failing buildkite/premerge run 68952. The single failed step is :ray-serve: serve: serve minimal [g16_s14], running //python/ray/serve/tests/.... This appears unrelated to this PR's autoscaler metrics reporter change path. Could a maintainer rerun the premerge job or share the failing serve log if there is an actionable PR-specific failure?