decentraland / marketplace-server / 32253422318

62%

push

github

feat: wearableGender filter on /v3/catalog/unified (#391)

The unified feed already reports a per-row `gender` (derived from the item's
body shapes), but never filtered on it: the handler doesn't read
`wearableGender`, so a caller sending it gets an unfiltered page that looks
filtered. /v1/items and /v2/catalog both honour the param, so the difference is
invisible until someone compares results.

That matters to an avatar-driven client: equipping a wearable that only ships
the other body shape leaves that slot naked, and the alternative — dropping
those rows client-side — returns short pages and an overstated total, since the
feed is paginated and reports its own count. Same reasoning the `listingType`
filter already documents.

The WHERE reuses the column, COALESCE and ::text[] cast of `genderExpr`, so
what the filter selects and what the row reports as `gender` cannot disagree.
`@>` is "declares all of these", which makes `wearableGender=male` mean
"wearable BY a male avatar" (male-exclusive plus unisex) rather than
male-exclusive only.

Two prior implementations disagree on the edge cases, so this follows the more
complete one:

- UNISEX asks for both body shapes, as in ports/items (ports/catalog ignores
  it). It is then the same request as MALE + FEMALE, which is exactly the set
  the response labels `unisex`.
- Both encodings are accepted: this feed's comma-separated lists (`rarity`,
  `wearableCategory`) and the repeated `&wearableGender=` form /v1/items takes.
  Reaching for the wrong one is what silently returns an unfiltered page.

Unknown values are dropped rather than passed through, so a typo leaves the
feed unfiltered instead of asking for a body shape no item declares.

1715 of 3149 branches covered (54.46%)

Branch coverage included in aggregate %.

18 of 18 new or added lines in 2 files covered. (100.0%)

3083 of 4537 relevant lines covered (67.95%)

26.82 hits per line