fix: prevent panic in uniqueItems validation for unhashable types (#1042)

[ArdyJunata]

Summary

Fixes #1042

Problem

The uniqueItems check in handleArray used map[any]struct{} as a hash set. When array items contain non-hashable types such as map[string]interface{} — produced by malformed JSON like [{}] for a []string field — inserting into the map panics:

http: panic serving [::1]:59220: hash of unhashable type: map[string]interface {}

This caused the server to return no response at all instead of a 422 Unprocessable Entity. The panic kills the goroutine serving the request.

Reproduction:

curl -X POST -H 'Content-Type: application/json' \
  -d '{"arrayOfStrings": [{}]}' \
  http://localhost:8888/demo
# Server logs: panic serving ...: hash of unhashable type: map[string]interface {}

Fix

Introduce a uniqueItemsContains helper that:

1. Fast path: attempts an O(1) map[any] lookup (works for all hashable types — strings, ints, bools, etc.)
2. Slow path: a deferred recover() catches the panic for unhashable types and falls back to an O(n) reflect.DeepEqual linear scan

This means:

• ✅ Normal arrays of hashable items → same O(n) performance as before
• ✅ Arrays with maps/slices → graceful O(n²) fallback, no panic
• ✅ Duplicate unhashable objects → still detected correctly
• ✅ Malformed [{}] for []string → proper 422 expected string error

Tests

Three regression tests added to validate_test.go:

Test	Verifies
uniqueItems with unhashable object element must not panic	[{}] for []string returns 422, not a panic
uniqueItems detects duplicate unhashable objects	[{"a":1},{"a":1}] is still detected as non-unique
uniqueItems with mixed hashable and unhashable elements	["ok", {"k":"v"}] does not panic

All existing tests continue to pass.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.15%. Comparing base (2b69054) to head (c15e7c9).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1045      +/-   ##
==========================================
+ Coverage   93.14%   93.15%   +0.01%     
==========================================
  Files          23       23              
  Lines        4901     4955      +54     
==========================================
+ Hits         4565     4616      +51     
- Misses        272      275       +3     
  Partials       64       64              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

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

[wolveix]

Thanks for tracking this down, @ArdyJunata! The panic fix is correct and the three regression tests cover the right cases.

I pushed a performance follow-up directly to your branch. uniqueItemsContains rebuilt a fresh map[any] from all previously-seen items on every element, which made the check O(n²) for every uniqueItems array, not only the unhashable case.

Benchmarks before and after the changes:

┌───────┬────────────────┬──────────────┬────────────────────┐
│ items │ before this PR │ with this PR │ with the follow-up │
├───────┼────────────────┼──────────────┼────────────────────┤
│ 1,000 │ 0.03 ms        │ 8.5 ms       │ 0.03 ms            │
├───────┼────────────────┼──────────────┼────────────────────┤
│ 4,000 │ 0.10 ms        │ 149 ms       │ 0.13 ms            │
└───────┴────────────────┴──────────────┴────────────────────┘

The follow-up keeps your recover approach; it grows a single map incrementally for hashable items (O(1) lookups, the common case) and only falls back to the reflect.DeepEqual scan for genuinely unhashable items.