fix: hscan count limit

[xDarksome]

Description

Resolves https://linear.app/reown/issue/WCN2-188/h-02-unbounded-client-controlled-hscan-count-drives-a-vecwith

How Has This Been Tested?

Not tested

Due Diligence

• Breaking change
• Requires a documentation update
• Requires a e2e/integration test update

[linear]

WCN2-188

[claude]

Claude finished @xDarksome's task in 1m 48s —— View job

---

Code Review Complete

Reviewed PR #337: fix: hscan count limit

Issues Found

Issue 1: Missing descriptive error message
File: crates/db/src/server.rs:174-176
Problem: Error returned without explaining the limit or why validation failed

if op.count > MAX_HSCAN_COUNT {
    return Error::invalid_argument();
}

Recommendation: Add descriptive message to help clients debug:

if op.count > MAX_HSCAN_COUNT {
    return Error::invalid_argument()
        .with_message(format!("HSCAN count {} exceeds maximum limit of {}", op.count, MAX_HSCAN_COUNT));
}

---

Issue 2: No test coverage
Problem: PR description states "Not tested" - security fix lacks validation

Recommendation: Add tests covering:

• Count at limit (5000) - should succeed
• Count exceeding limit (5001) - should return InvalidArgument error
• Count below limit - should succeed
• Verify error message includes limit information

---

Issue 3: Undocumented magic number
File: crates/db/src/server.rs:29

const MAX_HSCAN_COUNT: u32 = 5000;

Problem: No documentation explaining rationale for 5000

Recommendation: Add doc comment explaining choice:

/// Maximum allowed count for HSCAN operations to prevent unbounded memory allocation.
/// This limit prevents clients from requesting excessively large result sets that could
/// cause memory exhaustion on the server.
const MAX_HSCAN_COUNT: u32 = 5000;

---

Issue 4: Potential boundary clarification
File: crates/db/src/server.rs:174

Question: Validation uses op.count > MAX_HSCAN_COUNT. Should count of exactly 5000 be allowed? Current implementation allows 5000 (uses > not >=), which seems correct, but worth confirming this is intentional.

---

Security Assessment

✅ Fix correctly addresses unbounded client-controlled input vulnerability
✅ Proper error type (InvalidArgument) for client validation failure
✅ Error marked as non-transient (correct - client shouldn't retry)
✅ RPC error code mapping implemented correctly

---