yonlu/yellowjacket
1
1
Fork 0
Code Issues 55 Pull Requests 6 Actions Packages Projects Releases 12 Wiki Activity

queue-selection's name-click test depends on the scan's insert order #156

New Issue
Closed
opened 2026-08-20 04:19:19 +00:00 by logan · 1 comment
logan commented 2026-08-20 04:19:19 +00:00
Collaborator
Copy Link
Copy Source

Report

queue-selection.spec.ts — a click on a name navigates instead, and
that is the exception — fails on main on both engines:

Expected: "explore-album-details"
Received: "home"

It passed in its own PR (#152), passed two consecutive full-suite runs
locally, and fails on the merge commit. I added it; this is my defect.

Findings

The spec stages a queue from library.Library.GetTracks(0) and takes
the first few tracks, then clicks the name on row 2 to show that
explore-link takes the click and the row is therefore not selected.

explore-link routes a track name to its album's page, resolved by
name through findLocalAlbum. The fixture library contains tracks with
no album at all — 01 Tone A and 02 Tone B, whose Album cell is
empty in the track list — and a name with nothing to route to navigates
nowhere.

So which track lands on row 2 decides whether the test passes, and that
order is GetTracks' order, which is audio_files.id, which is the
order the scan inserted them in. Locally the seed's first eight
tracks are all from Glass Harbour and Long Way Round; CI rebuilds the
seed by running a real scan, whose insert order is a function of
concurrency and directory traversal. Measured locally: indices 0-7 all
have albums, which is exactly why this could not reproduce here.

The fixture had a requirement it did not state. "Any six tracks" is
not what the test needs; it needs "a track whose name can navigate".

Direction

Filter the staged queue to tracks with a non-empty album, so the
requirement is in the fixture rather than in the library's luck. Worth
checking the other specs that take GetTracks(0) and slice: the same
assumption may be load-bearing elsewhere, and the fixture library is
deliberately full of edge cases — untagged tracks, unicode, duplicates —
which is what makes "the first N tracks" a poor way to ask for an
ordinary one.

**Report** `queue-selection.spec.ts` — *a click on a name navigates instead, and that is the exception* — fails on `main` on **both** engines: ``` Expected: "explore-album-details" Received: "home" ``` It passed in its own PR (#152), passed two consecutive full-suite runs locally, and fails on the merge commit. I added it; this is my defect. **Findings** The spec stages a queue from `library.Library.GetTracks(0)` and takes the first few tracks, then clicks the *name* on row 2 to show that `explore-link` takes the click and the row is therefore not selected. `explore-link` routes a track name to **its album's page**, resolved by name through `findLocalAlbum`. The fixture library contains tracks with **no album at all** — `01 Tone A` and `02 Tone B`, whose Album cell is empty in the track list — and a name with nothing to route to navigates nowhere. So which track lands on row 2 decides whether the test passes, and that order is `GetTracks`' order, which is `audio_files.id`, which is the order the **scan** inserted them in. Locally the seed's first eight tracks are all from Glass Harbour and Long Way Round; CI rebuilds the seed by running a real scan, whose insert order is a function of concurrency and directory traversal. Measured locally: indices 0-7 all have albums, which is exactly why this could not reproduce here. **The fixture had a requirement it did not state.** "Any six tracks" is not what the test needs; it needs "a track whose name can navigate". **Direction** Filter the staged queue to tracks with a non-empty album, so the requirement is in the fixture rather than in the library's luck. Worth checking the other specs that take `GetTracks(0)` and slice: the same assumption may be load-bearing elsewhere, and the fixture library is deliberately full of edge cases — untagged tracks, unicode, duplicates — which is what makes "the first N tracks" a poor way to ask for an ordinary one.
logan added the Area/Queue
Priority
High
2
Kind/TestingKind/Bug
Reviewed
Confirmed
1
 labels 2026-08-20 04:19:19 +00:00
logan self-assigned this 2026-08-20 04:19:25 +00:00
logan added the
Status
In Progress
 label 2026-08-20 04:19:26 +00:00
logan commented 2026-08-20 04:19:26 +00:00
Author
Collaborator
Copy Link
Copy Source

Claiming this — it is my defect, from #152, and it has main red.
Branch: fix/156-queue-selection-fixture-order.

Fix is to state the requirement in the fixture: the staged queue takes
tracks that have an album, because that is what makes a track name
routable. Then the sweep the Direction asks for, over the other specs
that slice GetTracks(0).

Claiming this — it is my defect, from #152, and it has main red. Branch: `fix/156-queue-selection-fixture-order`. Fix is to state the requirement in the fixture: the staged queue takes tracks that have an album, because that is what makes a track name routable. Then the sweep the Direction asks for, over the other specs that slice `GetTracks(0)`.
logan closed this issue 2026-08-20 04:35:09 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-20 04:35:19 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Queue Kind/Bug Kind/Testing
Priority
High
2
Reviewed
Confirmed
1
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees logan
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#156