main is red and this is why.queue-selection's name-click test
fails on both engines on the merge commit, having passed in its own PR
(#152) and in two consecutive local full-suite runs. I added it; this is
my defect.
What it depended on without saying so
The spec staged a queue from the first few rows of GetTracks(0) and
clicked a track name, which explore-link routes to that track's album page. Four tracks in the fixture library have no album — 01 Tone A, 02 Tone B, Title Only, no-tags-at-all — and a name
with nothing to route to renders as plain text, not as a link.
Which tracks arrive first is audio_files.id order, which is the order
the scan inserted them, which depends on concurrency and directory
traversal. Locally the first eight are all from two proper albums, so it
passed twice over; CI rebuilds its seed with a real scan and got a
different eight.
And a loose locator turned that into a mystery
The row was located with .locator('.explore-link').first(). A row has two — the title and the artist. With the title as plain text, first() silently resolved to the artist link, so the click went
somewhere real and the assertion was about a destination the test had
never exercised. Confirmed against the running app: for 01 Tone A the
a11y tree shows the title as a bare generic and only the artist
carrying "View artist in your library".
Two fixes, and both are "say what you mean":
the staged queue asks for tracks that have an album
the click names .track-title .explore-link
Verification
Reproduced before fixing, by staging CI's condition deliberately —
sorting no-album tracks to the front, so row 2 is one:
fixture
result
no-album track at row 2 (CI's condition)
fails in 30.2s
filtered to tracks with an album
passes in 752ms
make e2e — 178 passed
npx tsc --noEmit in e2e/
The Direction's sweep found one other spec slicing GetTracks: queue-reorder, which asserts on order alone and needs no property of
the tracks it gets, so it is left alone.
.planning/NOTES.md carries the general form, because the fixture
library is deliberately full of edge cases: a spec that wants an
ordinary track has to ask for one, and slicing is not asking.
**`main` is red and this is why.** `queue-selection`'s name-click test
fails on both engines on the merge commit, having passed in its own PR
(#152) and in two consecutive local full-suite runs. I added it; this is
my defect.
## What it depended on without saying so
The spec staged a queue from the first few rows of `GetTracks(0)` and
clicked a track **name**, which `explore-link` routes to that track's
*album* page. Four tracks in the fixture library have **no album** —
`01 Tone A`, `02 Tone B`, `Title Only`, `no-tags-at-all` — and a name
with nothing to route to renders as plain text, not as a link.
Which tracks arrive first is `audio_files.id` order, which is the order
the **scan** inserted them, which depends on concurrency and directory
traversal. Locally the first eight are all from two proper albums, so it
passed twice over; CI rebuilds its seed with a real scan and got a
different eight.
## And a loose locator turned that into a mystery
The row was located with `.locator('.explore-link').first()`. A row has
**two** — the title and the artist. With the title as plain text,
`first()` silently resolved to the *artist* link, so the click went
somewhere real and the assertion was about a destination the test had
never exercised. Confirmed against the running app: for `01 Tone A` the
a11y tree shows the title as a bare `generic` and only the artist
carrying "View artist in your library".
Two fixes, and both are "say what you mean":
- the staged queue asks for tracks that **have an album**
- the click names `.track-title .explore-link`
## Verification
Reproduced before fixing, by staging CI's condition deliberately —
sorting no-album tracks to the front, so row 2 is one:
| fixture | result |
|---|---|
| no-album track at row 2 (CI's condition) | **fails in 30.2s** |
| filtered to tracks with an album | passes in 752ms |
- `make e2e` — 178 passed
- `npx tsc --noEmit` in `e2e/`
The Direction's sweep found one other spec slicing `GetTracks`:
`queue-reorder`, which asserts on order alone and needs no property of
the tracks it gets, so it is left alone.
`.planning/NOTES.md` carries the general form, because the fixture
library is *deliberately* full of edge cases: a spec that wants an
ordinary track has to ask for one, and slicing is not asking.
Closes #156
`queue-selection`'s name-click test failed on main on both engines,
having passed in its own PR and in two consecutive local suite runs. I
added it in #152; this is my defect and it had main red.
It staged a queue from the first few rows of `GetTracks(0)` and clicked
a track *name*, which `explore-link` routes to that track's **album**
page. Four tracks in the fixture library have no album — `01 Tone A`,
`02 Tone B`, `Title Only`, `no-tags-at-all` — and a name with nothing
to route to renders as plain text rather than as a link.
Which tracks arrive first is `audio_files.id` order, which is the order
the *scan* inserted them, which depends on concurrency and directory
traversal. Locally the first eight are all from two proper albums; CI
rebuilds its seed with a real scan and got a different eight. The
fixture had a requirement it did not state, so the queue now asks for
tracks that have an album.
A loose locator is what turned that into a mystery rather than a
message. The row was located with `.explore-link` and `first()`, and a
row has two — title and artist. With the title as plain text, `first()`
silently resolved to the *artist* link, so the click went somewhere
real and the assertion was about a destination the test had never
exercised. It names `.track-title .explore-link` now.
Reproduced before fixing, by staging the CI condition deliberately: a
no-album track at row 2 fails the test in 30s on this machine, and the
filtered fixture passes in 752ms.
The Direction's sweep found one other spec slicing `GetTracks` —
`queue-reorder`, which asserts on order alone and needs no property of
the tracks it gets, so it is left as it is.
Closes#156
logan
merged commit 86e7444603 into main2026-08-20 04:35:09 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
mainis red and this is why.queue-selection's name-click testfails on both engines on the merge commit, having passed in its own PR
(#152) and in two consecutive local full-suite runs. I added it; this is
my defect.
What it depended on without saying so
The spec staged a queue from the first few rows of
GetTracks(0)andclicked a track name, which
explore-linkroutes to that track'salbum page. Four tracks in the fixture library have no album —
01 Tone A,02 Tone B,Title Only,no-tags-at-all— and a namewith nothing to route to renders as plain text, not as a link.
Which tracks arrive first is
audio_files.idorder, which is the orderthe scan inserted them, which depends on concurrency and directory
traversal. Locally the first eight are all from two proper albums, so it
passed twice over; CI rebuilds its seed with a real scan and got a
different eight.
And a loose locator turned that into a mystery
The row was located with
.locator('.explore-link').first(). A row hastwo — the title and the artist. With the title as plain text,
first()silently resolved to the artist link, so the click wentsomewhere real and the assertion was about a destination the test had
never exercised. Confirmed against the running app: for
01 Tone Athea11y tree shows the title as a bare
genericand only the artistcarrying "View artist in your library".
Two fixes, and both are "say what you mean":
.track-title .explore-linkVerification
Reproduced before fixing, by staging CI's condition deliberately —
sorting no-album tracks to the front, so row 2 is one:
make e2e— 178 passednpx tsc --noEmitine2e/The Direction's sweep found one other spec slicing
GetTracks:queue-reorder, which asserts on order alone and needs no property ofthe tracks it gets, so it is left alone.
.planning/NOTES.mdcarries the general form, because the fixturelibrary is deliberately full of edge cases: a spec that wants an
ordinary track has to ask for one, and slicing is not asking.
Closes #156