Is your feature request related to a problem? Please describe.
nodeTypeIdFromTaintsAndLabels() in internal/scheduler/internaltypes/node_type.go:133 generates uint64 hashes via FNV-1a to identify node types. There is an existing TODO from the author:
TODO: We should test this function to ensure there are no collisions. And that the string is never empty.
Hash collisions here don't break correctness, but they reduce scheduling efficiency by grouping different node types together. A test would confirm the hash function behaves well for realistic inputs and let us remove the TODO.
Describe the solution you'd like
Add a test in internal/scheduler/internaltypes/node_type_test.go that:
- Generates a large number of realistic taint/label combinations (different taint keys, values, effects, and indexing label values)
- Computes the hash for each combination
- Asserts no two distinct inputs produce the same hash
- Verifies the hash input string is never empty
Getting started
Look at how NodeType is constructed in the existing code to understand what realistic inputs look like. You can use common Kubernetes taints (e.g., node.kubernetes.io/not-ready, node.kubernetes.io/unreachable) and labels (e.g., kubernetes.io/arch, topology.kubernetes.io/zone) to build test cases.
The project uses table-driven tests and testify/assert + require for assertions. Check other _test.go files in the same package for the style.
Acceptance criteria
- Test covers a meaningful number of combinations (hundreds to thousands)
- Test asserts no hash collisions
- Test asserts hash input string is never empty
go test ./internal/scheduler/internaltypes/... passes
- Remove the existing TODO comment once the test is in place
Is your feature request related to a problem? Please describe.
nodeTypeIdFromTaintsAndLabels()ininternal/scheduler/internaltypes/node_type.go:133generates uint64 hashes via FNV-1a to identify node types. There is an existing TODO from the author:Hash collisions here don't break correctness, but they reduce scheduling efficiency by grouping different node types together. A test would confirm the hash function behaves well for realistic inputs and let us remove the TODO.
Describe the solution you'd like
Add a test in
internal/scheduler/internaltypes/node_type_test.gothat:Getting started
Look at how
NodeTypeis constructed in the existing code to understand what realistic inputs look like. You can use common Kubernetes taints (e.g.,node.kubernetes.io/not-ready,node.kubernetes.io/unreachable) and labels (e.g.,kubernetes.io/arch,topology.kubernetes.io/zone) to build test cases.The project uses table-driven tests and
testify/assert+requirefor assertions. Check other_test.gofiles in the same package for the style.Acceptance criteria
go test ./internal/scheduler/internaltypes/...passes