Three rack state-controller handler tests were bare #[ignore]d -- silently never running in CI. Unignoring them (in #2694, part of #2692) surfaced that they fail against the current RackStateHandler::handle_object_state behavior: they assert state transitions the handler no longer makes. The handler either has a real gap, or these tests encode expectations from before a handler refactor; this issue is to determine which, then fix the handler or correct/remove the tests.
They are re-ignored with a reason (referencing this issue) rather than left bare, so the gap is visible and tracked instead of silent.
The three tests (crates/api-core/src/tests/rack_state_controller/handler.rs)
test_expected_incomplete_device_counts_stays -- a rack with a topology expecting more devices than exist (NVL72 profile, no expected rack registered) is asserted to yield DoNothing from the Created handler; the handler returns a different outcome.test_expected_more_discovered_than_expected_transitions -- a rack with more discovered compute trays than expected ("Single" profile) is asserted to Transition to Discovering; the handler returns a non-Transition outcome (observed discriminant 0). Note the test's setup comment ("simulate more discovered than expected") does not actually arrange that state via db_rack::update, so the test fixture itself may be incomplete.test_discovering_waits_for_compute_ready -- the Discovering handler is asserted to error when a compute tray has no managed-host record; the handler returns a non-error result.
What to do
For each: read the current Created/Discovering handling, decide whether the handler should behave as the test asserts (then fix the handler) or whether the assertion is stale (then rewrite it to pin current behavior, or delete it if obsolete). Build the fixtures so each test exercises the state it claims to. Remove the #[ignore] once green.
(The fourth formerly-ignored test, test_expected_zero_topology_transitions_to_discovering, was only broken by a duplicate db_rack::create in its setup -- fixed and re-enabled in #2694. The always-true matches! assertion in machine_states::test_state_outcome was also fixed there.)
Surfaced by #2694 / #2692.
Three rack state-controller handler tests were bare
#[ignore]d -- silently never running in CI. Unignoring them (in #2694, part of #2692) surfaced that they fail against the currentRackStateHandler::handle_object_statebehavior: they assert state transitions the handler no longer makes. The handler either has a real gap, or these tests encode expectations from before a handler refactor; this issue is to determine which, then fix the handler or correct/remove the tests.They are re-ignored with a reason (referencing this issue) rather than left bare, so the gap is visible and tracked instead of silent.
The three tests (
crates/api-core/src/tests/rack_state_controller/handler.rs)test_expected_incomplete_device_counts_stays-- a rack with a topology expecting more devices than exist (NVL72 profile, no expected rack registered) is asserted to yieldDoNothingfrom theCreatedhandler; the handler returns a different outcome.test_expected_more_discovered_than_expected_transitions-- a rack with more discovered compute trays than expected ("Single" profile) is asserted toTransitiontoDiscovering; the handler returns a non-Transitionoutcome (observed discriminant 0). Note the test's setup comment ("simulate more discovered than expected") does not actually arrange that state viadb_rack::update, so the test fixture itself may be incomplete.test_discovering_waits_for_compute_ready-- theDiscoveringhandler is asserted to error when a compute tray has no managed-host record; the handler returns a non-error result.What to do
For each: read the current
Created/Discoveringhandling, decide whether the handler should behave as the test asserts (then fix the handler) or whether the assertion is stale (then rewrite it to pin current behavior, or delete it if obsolete). Build the fixtures so each test exercises the state it claims to. Remove the#[ignore]once green.(The fourth formerly-ignored test,
test_expected_zero_topology_transitions_to_discovering, was only broken by a duplicatedb_rack::createin its setup -- fixed and re-enabled in #2694. The always-truematches!assertion inmachine_states::test_state_outcomewas also fixed there.)Surfaced by #2694 / #2692.