IsFavorite and IsLiked are ignored by every by-name listing, so Favorites shows the whole library #180

New issue

Closed

opened 2026-08-22 17:01:27 +02:00 by Claude · 1 comment

Claude commented

2026-08-22 17:01:27 +02:00

Collaborator

Found on the Favorites tab of the throwaway instance in TESTCONTAINER/,
with exactly one favourite marked in the whole library.

What it looks like

Movies correctly holds the one film. Under it, Studios lists every studio
in the library — 1.21 Entertainment, 6th & Idaho Motion Picture Company, 20th
Century Fox … — and People lists every person. Nothing there was favourited.

What answers

With one favourite film and no other user data at all:

request	answered	in the library
`/Studios?IsFavorite=true`	498	498
`/Persons?IsFavorite=true`	4405	4405
`/Genres?IsFavorite=true`	25	25
`/Artists?IsFavorite=true`	179	179
`/MusicGenres?IsFavorite=true`	220	220
`/Items?IsFavorite=true&IncludeItemTypes=Movie`	1	284

IsFavorite=false answers 498 as well, and IsLiked=true answers 498 — so the
by-name routes are not answering true for everything, they are dropping the
narrowing altogether. /Items honours it.

Where to start

The by-name routes build their query without the user-data predicates /Items
adds. Whatever /Items does with IsFavorite and IsLiked has to reach the
by-name listings; the harness's note about a by-name listing narrowing the name
rows themselves as well as the items they were gathered from is the shape to
follow.

How to know it is done

A favourited studio and a favourited person are the only rows
/Studios?IsFavorite=true and /Persons?IsFavorite=true answer with,
IsFavorite=false answers with the rest, and the Favorites tab shows what was
favourited. This is a request no committed scenario makes, so it wants one.

House rules

Tests run under cargo nextest; upstream's source is the checkout in
upstream/ at the pin. Generated artifacts are regenerated, never edited.

Found on the **Favorites** tab of the throwaway instance in `TESTCONTAINER/`, with exactly one favourite marked in the whole library. ## What it looks like `Movies` correctly holds the one film. Under it, `Studios` lists *every* studio in the library — 1.21 Entertainment, 6th & Idaho Motion Picture Company, 20th Century Fox … — and `People` lists every person. Nothing there was favourited. ## What answers With one favourite film and no other user data at all: | request | answered | in the library | |---|---|---| | `/Studios?IsFavorite=true` | 498 | 498 | | `/Persons?IsFavorite=true` | 4405 | 4405 | | `/Genres?IsFavorite=true` | 25 | 25 | | `/Artists?IsFavorite=true` | 179 | 179 | | `/MusicGenres?IsFavorite=true` | 220 | 220 | | `/Items?IsFavorite=true&IncludeItemTypes=Movie` | 1 | 284 | `IsFavorite=false` answers 498 as well, and `IsLiked=true` answers 498 — so the by-name routes are not answering *true* for everything, they are dropping the narrowing altogether. `/Items` honours it. ## Where to start The by-name routes build their query without the user-data predicates `/Items` adds. Whatever `/Items` does with `IsFavorite` and `IsLiked` has to reach the by-name listings; the harness's note about a by-name listing narrowing the name rows themselves as well as the items they were gathered from is the shape to follow. ## How to know it is done A favourited studio and a favourited person are the only rows `/Studios?IsFavorite=true` and `/Persons?IsFavorite=true` answer with, `IsFavorite=false` answers with the rest, and the Favorites tab shows what was favourited. This is a request no committed scenario makes, so it wants one. ### House rules Tests run under `cargo nextest`; upstream's source is the checkout in `upstream/` **at the pin**. Generated artifacts are regenerated, never edited.

Claude added the

label

2026-08-22 17:01:51 +02:00

Claude referenced this issue

2026-08-22 18:18:08 +02:00

The row standing for a name is picked before the filters, not after #183

Claude commented

2026-08-22 18:18:35 +02:00

Author

Collaborator

Fixed in 47b18ec, with the review's findings in db0bad8.

Measured against the reference instance at the pin rather than read: a person
marked there is the only one /Persons?IsFavorite=true answers with, and
/Artists and /Artists/AlbumArtists narrow the same way.

Three things the review corrected on top of the first pass:

The pinned client sends the other spelling. It asks the Artists,
AlbumArtists and Authors tabs with Filters=IsFavorite and only Studios with
isFavorite, so the first pass fixed the tab that was least broken. The two
spellings disagree about which wins: PersonsController reads the list only
where no isFavorite was spelled out, ArtistsController applies the list
after the parameter and so turns the mark on over an explicit false, and
the genre and studio listings declare no list at all. All three measured.
/Years declares no isFavorite. Binding it to a flag on the params the
six listings share turned GET /Years?isFavorite=yes into a 400 where
upstream answers 200, and an empty isFavorite= into a 400 on all six.
IsLiked is left alone on /Persons, where upstream answers the whole
listing for either value. It is not ignored on the other four — upstream's
outer filter carries IsLiked and IsFavoriteOrLiked — but both are only
reachable through Filters on /Artists, and neither is supported here.
That gap is older than this issue.

One thing the review turned up that is not this issue and is now #183: the row
standing for a name is picked before the filters rather than after, so an
account that cannot see the representative — or a mark on the row that loses
the pick — answers differently from upstream.

Fixed in `47b18ec`, with the review's findings in `db0bad8`. Measured against the reference instance at the pin rather than read: a person marked there is the only one `/Persons?IsFavorite=true` answers with, and `/Artists` and `/Artists/AlbumArtists` narrow the same way. Three things the review corrected on top of the first pass: - **The pinned client sends the other spelling.** It asks the Artists, AlbumArtists and Authors tabs with `Filters=IsFavorite` and only Studios with `isFavorite`, so the first pass fixed the tab that was least broken. The two spellings disagree about which wins: `PersonsController` reads the list only where no `isFavorite` was spelled out, `ArtistsController` applies the list *after* the parameter and so turns the mark on over an explicit `false`, and the genre and studio listings declare no list at all. All three measured. - **`/Years` declares no `isFavorite`.** Binding it to a flag on the params the six listings share turned `GET /Years?isFavorite=yes` into a `400` where upstream answers `200`, and an empty `isFavorite=` into a `400` on all six. - `IsLiked` is left alone on `/Persons`, where upstream answers the whole listing for either value. It is *not* ignored on the other four — upstream's outer filter carries `IsLiked` and `IsFavoriteOrLiked` — but both are only reachable through `Filters` on `/Artists`, and neither is supported here. That gap is older than this issue. One thing the review turned up that is not this issue and is now #183: the row standing for a name is picked before the filters rather than after, so an account that cannot see the representative — or a mark on the row that loses the pick — answers differently from upstream.

Claude closed this issue

2026-08-22 18:18:35 +02:00