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

queue-selection.spec.ts names two fixture tracks that now have an album #217

New Issue
Closed
opened 2026-08-24 09:45:08 +00:00 by logan · 2 comments
logan commented 2026-08-24 09:45:08 +00:00
Collaborator
Copy Link
Copy Source

Finding

e2e/specs/queue-selection.spec.ts picks the tracks it queues with

.filter((t) => t.TrackName !== longTitle && t.Album !== '')

and a long comment explaining that the filter is needed because "the
fixture library deliberately contains two [albumless tracks] (01 Tone A, 02 Tone B)".

Since #104 those two are not albumless: they are WAVs, they have been
tagged on disk all along (album Test Tones, artist Field Recordings), and the scanner can read a WAV's tags now. The comment
names the wrong files.

What is still true

The filter itself, and the reason for it. Two fixture tracks genuinely
have no album — unsorted/no-tags-at-all.mp3 and
unsorted/title-only.mp3 — so the spec's premise holds and it passes:
239 e2e specs green on the #104 branch, this one included. This is a
comment that has stopped describing the library, not a broken test.

Why it was not fixed there

Seven PRs from earlier runs are open against an unmoved main and
between them edit more than twenty files under frontend/src,
frontend/test and e2e/specs. #104 is backend Go and was kept out of
that surface on purpose; a two-line comment edit is not worth an eighth
branch into it. Whoever next touches this spec should fix the two names
in passing.

**Finding** `e2e/specs/queue-selection.spec.ts` picks the tracks it queues with ```ts .filter((t) => t.TrackName !== longTitle && t.Album !== '') ``` and a long comment explaining that the filter is needed because "the fixture library deliberately contains two [albumless tracks] (`01 Tone A`, `02 Tone B`)". Since #104 those two are not albumless: they are WAVs, they have been tagged on disk all along (album `Test Tones`, artist `Field Recordings`), and the scanner can read a WAV's tags now. The comment names the wrong files. **What is still true** The filter itself, and the reason for it. Two fixture tracks genuinely have no album — `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3` — so the spec's premise holds and it passes: 239 e2e specs green on the #104 branch, this one included. This is a comment that has stopped describing the library, not a broken test. **Why it was not fixed there** Seven PRs from earlier runs are open against an unmoved `main` and between them edit more than twenty files under `frontend/src`, `frontend/test` and `e2e/specs`. #104 is backend Go and was kept out of that surface on purpose; a two-line comment edit is not worth an eighth branch into it. Whoever next touches this spec should fix the two names in passing.
logan added the Kind/Testing
Reviewed
Confirmed
1
Priority
Low
4
 labels 2026-08-24 09:45:08 +00:00
logan self-assigned this 2026-08-26 11:38:16 +00:00
logan added the
Status
In Progress
 label 2026-08-26 11:38:17 +00:00
logan commented 2026-08-26 11:38:17 +00:00
Author
Collaborator
Copy Link
Copy Source

Picking this up on branch test/217-fixture-names-in-queue-selection.

The premise checks out against the running app, asked of the database
rather than of the comment. 01 Tone A.wav / 02 Tone B.wav scan in
as titles Tone A / Tone B on album Test Tones, and exactly two
tracks in the library have no album at all:
unsorted/no-tags-at-all.mp3 and unsorted/title-only.mp3.

So the filter and its whole reason stay; only the two names in the
comment change, plus a clause saying which change made them wrong, so
the next reader does not put the WAVs back.

Picking this up on branch `test/217-fixture-names-in-queue-selection`. The premise checks out against the running app, asked of the database rather than of the comment. `01 Tone A.wav` / `02 Tone B.wav` scan in as titles `Tone A` / `Tone B` on album **Test Tones**, and exactly two tracks in the library have no album at all: `unsorted/no-tags-at-all.mp3` and `unsorted/title-only.mp3`. So the filter and its whole reason stay; only the two names in the comment change, plus a clause saying which change made them wrong, so the next reader does not put the WAVs back.
logan commented 2026-08-26 11:57:57 +00:00
Author
Collaborator
Copy Link
Copy Source

PR: #226 — CI green
(check and e2e, WebKit included).

The names came from the running app rather than from the fixture
generator: 31 tracks, exactly two with no album
(unsorted/no-tags-at-all.mp3, unsorted/title-only.mp3), and the two
WAVs on album Test Tones. The filter and every assertion are
unchanged; a clause now says which change made the old names wrong.

The same #104 staleness in .pi/skills/yellowjacket-dev/references/fixtures.md
and twice in .planning/NOTES.md is filed as #225 rather than folded in
here.

PR: https://git.ljones.me/yonlu/yellowjacket/pulls/226 — CI green (`check` and `e2e`, WebKit included). The names came from the running app rather than from the fixture generator: 31 tracks, exactly two with no album (`unsorted/no-tags-at-all.mp3`, `unsorted/title-only.mp3`), and the two WAVs on album `Test Tones`. The filter and every assertion are unchanged; a clause now says which change made the old names wrong. The same #104 staleness in `.pi/skills/yellowjacket-dev/references/fixtures.md` and twice in `.planning/NOTES.md` is filed as #225 rather than folded in here.
logan closed this issue 2026-08-26 16:02:54 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-08-26 16:03:10 +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 Kind/Testing
Priority
Low
4
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#217