Two fields of a search hint are not what upstream sends #68

New issue

Closed

opened 2026-08-04 13:58:17 +02:00 by Claude · 1 comment

Claude commented

2026-08-04 13:58:17 +02:00

Collaborator

Two fields of a search hint are not what upstream sends.

Measured on /Search/Hints against a production library, 3 differences:

Status is never set for a Series (SearchController.cs:184 sets it
only there), and this server sends it.
Album comes from an ancestry walk here, where upstream reads the track's
own AlbumEntity/Album (SearchController.cs:197-207).

Found while fixing #64, and unrelated to it — they were invisible while the
route answered nothing for the user id the scenario names.

Two fields of a search hint are not what upstream sends. Measured on `/Search/Hints` against a production library, 3 differences: - **`Status`** is never set for a `Series` (`SearchController.cs:184` sets it only there), and this server sends it. - **`Album`** comes from an ancestry walk here, where upstream reads the track's own `AlbumEntity`/`Album` (`SearchController.cs:197-207`). Found while fixing #64, and unrelated to it — they were invisible while the route answered nothing for the user id the scenario names.

Claude referenced this issue

2026-08-04 14:35:55 +02:00

A listing asked for a user that is not there answers with nothing #64

Claude commented

2026-08-04 15:18:11 +02:00

Author

Collaborator

Fixed, and both halves of this issue were stated backwards.

Status — upstream sends "Continuing" for a series and this server sent
nothing. It is now gated to Series, which is what SearchController.cs:184
does.

Album — upstream reads the track's own AlbumEntity (Audio.cs:61, a
FindParent<MusicAlbum>), and this server sent the track's Album column.
Now read from the album row, falling back to the column when nothing above the
track is an album. AlbumId already agreed.

Measured: the 3 search-hint differences in the bundle scenario are gone, and
that scenario now reports 0.

Fixed, and **both halves of this issue were stated backwards.** `Status` — upstream sends `"Continuing"` for a series and this server sent nothing. It is now gated to `Series`, which is what `SearchController.cs:184` does. `Album` — upstream reads the track's own `AlbumEntity` (`Audio.cs:61`, a `FindParent<MusicAlbum>`), and this server sent the track's `Album` *column*. Now read from the album row, falling back to the column when nothing above the track is an album. `AlbumId` already agreed. Measured: the 3 search-hint differences in the `bundle` scenario are gone, and that scenario now reports **0**.

Claude closed this issue

2026-08-04 15:18:11 +02:00