The Pinned tab shows everything, and Currently Listening only looks at one page #6

New Issue

rays · 2026-09-20T06:54:08-07:00

rays commented

2026-09-20 06:54:08 -07:00

Two filters in the API client do not say what the server understands, and both fail quietly.

IPX.Filter.pinned sends filter=pinned. ipx's Filter::parse knows unread, downloaded, flagged and in_progress, and anything else falls through to All — so the Pinned tab is not filtering at all, it is showing every item and looking like it worked. The page sends flagged for that tab; the column is still named for the flag it was before it was called pinned in the interface.

Currently Listening is worse in kind. ipx has filter=in_progress for exactly this — started past the first few seconds and short of the 90% the UI calls finished, measured against the length this person's player reported where there is one. The client does not send it. It asks for everything and then filters the fifty rows it happened to receive, so the view shows whichever started episodes are near the top of the whole library and silently omits the rest, and its count is wrong.

Both were written without checking db.rs for what the filter values actually are, which the page had right all along.

Fix: in_progress becomes a filter case, pinned sends flagged, and Currently Listening asks the server rather than trimming a page. Worth a test per filter that asserts what comes back matches the filter's meaning, since the failure mode here is a filter that returns plausible rows.

Two filters in the API client do not say what the server understands, and both fail quietly. `IPX.Filter.pinned` sends `filter=pinned`. ipx's `Filter::parse` knows `unread`, `downloaded`, `flagged` and `in_progress`, and anything else falls through to All — so the Pinned tab is not filtering at all, it is showing every item and looking like it worked. The page sends `flagged` for that tab; the column is still named for the flag it was before it was called pinned in the interface. Currently Listening is worse in kind. ipx has `filter=in_progress` for exactly this — started past the first few seconds and short of the 90% the UI calls finished, measured against the length this person's player reported where there is one. The client does not send it. It asks for everything and then filters the fifty rows it happened to receive, so the view shows whichever started episodes are near the top of the whole library and silently omits the rest, and its count is wrong. Both were written without checking `db.rs` for what the filter values actually are, which the page had right all along. Fix: `in_progress` becomes a filter case, `pinned` sends `flagged`, and Currently Listening asks the server rather than trimming a page. Worth a test per filter that asserts what comes back matches the filter's meaning, since the failure mode here is a filter that returns plausible rows.

rays added the bug label 2026-09-20 06:54:08 -07:00

rays referenced this issue from a commit

2026-09-20 06:56:31 -07:00

Send the filter names ipx actually understands (#6)

rays commented

2026-09-20 06:56:50 -07:00

Fixed in 14170fe.

pinned now sends flagged, and Currently Listening asks the server for in_progress instead of trimming the page it happened to receive.

The tests assert what each filter means rather than how many rows it returns — every unread row unread, every downloaded row with a file, every pinned row pinned, every in-progress row started — because the failure here was a full page of entirely plausible rows, which no count-based assertion would have caught. Pinned also has to match fewer than everything, which is the shape the bug took.

Seventeen tests pass.

Fixed in 14170fe. `pinned` now sends `flagged`, and Currently Listening asks the server for `in_progress` instead of trimming the page it happened to receive. The tests assert what each filter *means* rather than how many rows it returns — every unread row unread, every downloaded row with a file, every pinned row pinned, every in-progress row started — because the failure here was a full page of entirely plausible rows, which no count-based assertion would have caught. Pinned also has to match fewer than everything, which is the shape the bug took. Seventeen tests pass.

rays closed this issue

2026-09-20 06:56:50 -07:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: rays/ipodderx-app#6