Add channel storage prop array support

[tudddorrr]

No description provided.

[codecov]

Codecov Report

❌ Patch coverage is 98.54015% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 97.39%. Comparing base (5ee7c47) to head (a3f083a).
⚠️ Report is 2 commits behind head on develop.

Files with missing lines	Patch %	Lines
src/routes/api/game-channel/put-storage.ts	97.91%	0 Missing and 2 partials ⚠️

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #908      +/-   ##
===========================================
+ Coverage    97.32%   97.39%   +0.06%     
===========================================
  Files          405      405              
  Lines         6540     6599      +59     
  Branches       858      870      +12     
===========================================
+ Hits          6365     6427      +62     
+ Misses          90       88       -2     
+ Partials        85       84       -1     

☔ View full report in Codecov by Sentry.
📢 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[claude]

PR Review: Add channel storage prop array support

Major Issue

flatten() returns inconsistent format for single-element array props

In src/entities/game-channel-storage-prop.ts, the early-return optimisation for single props breaks array key semantics:

When an array key (e.g. items[]) has exactly one row, flatten returns value as a plain string. With two or more rows it returns value as a JSON-encoded array string. Clients using JSON.parse(prop.value) on array-keyed props will get inconsistent types depending on how many elements are stored.

The fix is to branch on isArrayKey rather than props.length:

// before: if (props.length === 1) return props[0].toJSON()
if (props.length === 1 && !isArrayKey(props[0].key)) return props[0].toJSON()

const sorted = [...props].sort((a, b) => b.updatedAt.getTime() - a.updatedAt.getTime())
const representative = sorted[0].toJSON()
representative.value = JSON.stringify(sorted.map((p) => p.value))
return representative

No existing test covers single-element array retrieval in get-storage or list-storage.

---

Minor Issue

processArrays - createdBy sort mutates local array in-place

In put-storage.ts, existingForKey.sort(...) mutates the array that the deletion loop below also iterates. Using [...existingForKey].sort(...) avoids an implicit order dependency (harmless now but fragile).

---

No issues found in: performance, security, or overall test coverage.

[claude]

Overall this is a well-structured PR with good test coverage. A couple of things worth addressing.

[claude]

PR Review: Add channel storage prop array support

Overall this is a well-structured PR with good test coverage. A few concrete issues worth addressing:

---

Potential Bugs

get-storage.ts: persistToRedis is now called unconditionally (including when no prop exists)

Previously the cache write was gated on result being non-null. The new code always writes to Redis — for missing props, it caches JSON.stringify(null) = "null". The cache-hit path correctly parses this back as null, so functional behavior is fine. However, there is no test verifying this negative-cache path: a first request for a non-existent key writes "null" to Redis, and a subsequent request should return null from cache without hitting the DB. The existing "should return null" test only exercises the DB path.

---

Minor Issues

flatten: sort by createdAt is non-deterministic for simultaneous inserts

Array items created in the same transaction (e.g. via a single PUT with multiple items[] values) will share the same createdAt millisecond, so their relative order is unstable. The serialised value could differ between reads. Tests guard against this with .sort(), which suggests it is accepted, but a tiebreaker (e.g. by id) would make ordering consistent within a response lifetime.

list-storage: no Redis cache test for array props

get-storage.test.ts has "should return prop arrays from redis if available" which verifies the cache-hit path for array keys. list-storage.test.ts adds the DB-path array tests but is missing the Redis cache-hit equivalent. Given that list-storage has its own grouping and flattening logic in the cache-miss branch, a two-request test that primes the cache would add meaningful confidence.