golem15/summercms
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(14.2-03): record the manual session, its findings and fixes in UAT

Browse Source
This commit is contained in:
Jakub Zych
2026-10-11 20:34:55 +02:00
parent 4660f95e5c
commit b9de0610d7
2 changed files with 62 additions and 14 deletions
Download Patch File Download Diff File Expand all files Collapse all files

73
.planning/phases/14.2-local-fonoteka-frontend-on-local-summercms-backend/14.2-UAT.md
View File

@@ -1,7 +1,7 @@
---
phase: 14.2-local-fonoteka-frontend-on-local-summercms-backend
plan: 03
status: pending-manual-session
status: open-reverify-and-php
---
# Phase 14.2 UAT: vue-fonoteka-app on the local Go backend
@@ -13,6 +13,7 @@ This file records the D-13 manual session (plan 03, Task 4) and the D-11 PHP cro
- Go gate subset (D-15) through `fonoteka.go/scripts/dev-stack.sh e2e`. Specs: `auth.setup.ts`, `login.spec.ts`, `smoke.spec.ts`, `fonoteka-item.spec.ts`, `public-share.spec.ts`, `realtime.spec.ts`, `i18n.spec.ts`, `album-edit-rate-cover.spec.ts`, `album-search.spec.ts`, `wishlist.spec.ts`. Result: `expected=17 unexpected=0 skipped=0 flaky=0`, `e2e-verdict: passed`.
- The realtime live test passed against the shared Centrifugo after the D-18/D-23 operator step: a connect reply, an error-free `collection:` subscribe and a push on that channel after an API album create.
- Commits tested: vue-fonoteka-app `c1f323a`; fonoteka.go `7675d64`.
- Re-run after the session fixes (2026-10-11): the same 10 spec files give `expected=17 unexpected=0 skipped=0 flaky=0`, `e2e-verdict: passed`. Tested with fonoteka.go `807dfdb`, summercms.go `4660f95`, vue-fonoteka-app `c1f323a`. Afterwards `grep -cE 'status=5[0-9]{2}' tmp/dev-stack/go.log` printed 0.
## PHP cross-check (Task 3): deferred
@@ -43,18 +44,64 @@ Item 11 passes only on a run with no skipped, unexpected or flaky test. Until th
## Manual session (Task 4, D-13)
Pending: the developer's session against the Go stack.
Session by the developer on 2026-10-11 (about 20:10 to 20:20 local time) against the Go stack. Commits tested: fonoteka.go `7675d64`, summercms.go `66dbd5a` (framework), vue-fonoteka-app `c1f323a`. The session's Go log is kept as `fonoteka.go/tmp/dev-stack/go.log.uat-session-20261011`.
| # | Item | Result | Notes |
|---|------|--------|-------|
| 1 | Login lands outside /login | pending | |
| 2 | Collections: "Moja kolekcja" lists Kind of Blue, Blue Train, Mingus Ah Um with covers | pending | |
| 3 | Album detail page opens | pending | |
| 4 | Search "Mingus" finds the album; no `album search engine failed` in go.log | pending | |
| 5 | Edit name persists after reload | pending | |
| 6 | Rating persists after reload | pending | |
| 7 | Cover upload shows on the page | pending | |
| 8 | Wishlist add on /wishlist/new, then remove | pending | |
| 9 | Realtime: `collection:` subscribe without error; push frame after an edit in a second tab | pending | |
| 10 | No 5xx in go.log; no `X-Powered-By: PHP` through :3119 | pending | |
| 11 | PHP cross-check (deferred above) | pending | |
| 1 | Login lands outside /login | pass | |
| 2 | Collections: "Moja kolekcja" lists Kind of Blue, Blue Train, Mingus Ah Um with covers | pass | |
| 3 | Album detail page opens | pass | |
| 4 | Search "Mingus" finds the album; no `album search engine failed` in go.log | pass | search_fail = 0 |
| 5 | Edit name persists after reload | pass | Session finding A (empty artist field) below; fixed. |
| 6 | Rating persists after reload | pass | |
| 7 | Cover upload shows on the page | fail, then analysed: matches PHP | See finding B. Re-verify. |
| 8 | Wishlist add on /wishlist/new, then remove | pass | Also marked an existing entry purchased. |
| 9 | Realtime: `collection:` subscribe without error; push frame after an edit in a second tab | push pass; UI refresh by frontend design | See finding C. The subscribe reply had no error and the push arrived. |
| 10 | No 5xx in go.log; no `X-Powered-By: PHP` through :3119 | fail, then fixed | See finding D. No PHP header; search_fail = 0. |
| 11 | PHP cross-check (deferred above) | pending | Not run yet. The plan stays open until it passes (D-11). |
### Finding A: the artist field in the edit form was empty (fixed in Go)
- **Symptom:** the collection view showed "John Coltrane" for Blue Train, but the Artist field of the edit form was empty.
- **Cause:** `fonoteka:dev-seed` set only `artist_display` and attached no artist rows, so `GET /albums/3` answered `"artists":[]`. The edit form fills the field from `album.artists` (`utils/album-draft.ts`).
- **Fix:** fonoteka.go `d31e00a`. The seed creates albums with `artists: [<name>]` through `classes.CreateAlbum`, the album form's path. A rerun attaches the artist to a seeded album that has no artist rows and reports `album …: updated`. `TestDevStackSmoke` covers both cases.
- **After the fix:** the restart printed `album Kind of Blue: updated`, `album Blue Train: updated` and `wishlist album A Love Supreme: updated`. `GET /albums/3` now answers `artists: ["John Coltrane"]`. Mingus Ah Um already had the artist set during the session.
- **Other write paths:** every non-seed album create goes through `classes.CreateAlbum`, the port of `AlbumWriteService::create`. That covers the album form, the wishlist form, bulk and CSV import. The create rules require `artists` (`required|array|min:1`, also per bulk row), as in PHP. The seed was the only path without artist rows.
### Finding B: a new cover does not become the main cover (matches PHP, not a Go defect)
- **Frontend:** both the edit gallery (`PhotoUploader.vue` `editHeroSrc`) and the detail page (`AlbumCoverGallery.vue` `hero`) show `photos[0]` as the main cover.
- **PHP:** `Album::$attachMany['photos']` is ordered by `sort_order`, and Winter's `Sortable` trait sets `sort_order` to the new file id on create (`vendor/winter/storm/src/Database/Traits/Sortable.php`). A new photo is therefore appended, and the oldest photo stays the main cover.
- **Go:** `classes.AttachAlbumPhoto` sets `sort_order = id`, and the DTO orders by `sort_order, id`.
- **Reproduction on Go** (album with photo A, then photo B uploaded through the edit form):
- API order is `[A, B]`.
- In the edit page right after the upload, the hero is A and the strip is `[A, B]`.
- After F5, the hero is still A.
- The upload answer has the PHP shape: `201 {"data":{"id","url","thumb_url"}}`.
- **The developer's session:** the log has two photo POSTs at 20:15:10 and 20:15:16, then `DELETE /albums/{id}/photos/{fileId}` at 20:15:23. The access log does not record the album id. The main cover changes only when `photos[0]` changes, for example when the older photo is deleted. That fits a new photo that showed as the main cover only later.
- **Re-verify:** item 7 means "the uploaded photo shows on the page", and the photo appears in the strip at once. A new photo replacing the main cover is not PHP behaviour.
### Finding C: realtime push arrives, no UI refresh for the same user (frontend design, same on PHP)
- **The Go push frame on `collection:2`:** `{"event":"updated.fonoteka.album","payload":{"id","collection_id","action","actor":{"user_id":2,"name":"Demo"},"timestamp","album"},"timestamp"}`.
- **The PHP publication:** the same keys at both levels. `CentrifugoClient::publish` sends `data: {event, payload, timestamp}`, and the payload comes from `Album::getBroadcastPayload` (`id`, `collection_id`, `action`, `actor`, `timestamp`, `album`).
- **The frontend's self-echo guard:** `useRealtimeSync.ts` skips the refresh when `payload.actor.user_id === auth.user.id`. Both tabs were logged in as the same user, so the second tab's edit is the first tab's own echo, and it is suppressed on purpose. Against PHP it behaves the same.
- **Re-verify:** for a UI refresh, edit from a different user who shares the collection (a household member).
### Finding D: a cancelled request was logged as a 500 (fixed in the framework)
- **What was logged:** `GET /_fonoteka/api/v1/genres status=500` at 20:18:34. The client cancelled the request, `classes/active_collection.go:204` failed with `context canceled`, and the handler wrote a 500 that no client received. PHP keeps running after a client disconnect and does not log a server error.
- **Fix:** summercms.go `4660f95`. The surf access log records a 5xx written after the request context ended with `context.Canceled` as 499 (client closed request). A real 5xx on a live request keeps its status.
- **Tests and docs:** `TestAccessLogClientClosedRequest` covers both cases. The surf README and `docs/services/logging.md` are updated.
- **Left as is:** the GORM logger still prints the `context canceled` line in colour; that is the known GORM log noise in `deferred-items.md`.
### Also fixed during the session follow-up
- fonoteka.go `807dfdb`: `dev-stack.sh e2e` exports `TMPDIR=tmp/dev-stack/go-tmp`. The session renamed the seeded "Kind of Blue" to "Kind of Blue!", so the next `fonoteka:dev-seed` run in `auth.setup.ts` created a new "Kind of Blue" album and had to write a new cover. It and failed with `invalid cross-device link`. This is the deferred file-bucket issue, now covered on the e2e path too.
### For the developer to re-verify
- **Artist field:** open Edit on Blue Train; the field shows John Coltrane.
- **Item 7:** upload a photo to an album that has a cover. It appears in the photo strip right away, and the main cover stays the first photo. To make it the main cover, delete the old one.
- **Item 9 (optional):** an edit by another household member refreshes the open page.
- **Item 11:** the PHP run described in the deferred section.

3
.planning/phases/14.2-local-fonoteka-frontend-on-local-summercms-backend/deferred-items.md
View File

@@ -9,5 +9,6 @@
- **vue-fonoteka-app contract test fails on HEAD before this plan.** `tests/contracts/missing-catalog.test.mjs` ("Album DTO carries label, catalog_number and country without any") matches `\bany\b` against the Album type and trips on the comment "the cheapest current listing in any condition" added by vue-fonoteka-app `984031f` (feat(e5o)). `pnpm test:contracts`: 278 pass, 1 fail. It is an `app/` type comment, which this phase must not change (D-20).
- **lagoon.Validate treats a pointer to "" as a value.** `isEmptyValue` returns false for a non-nil `*string` holding "", so a `nullable|in:` model rule fails where Laravel skips every non-implicit rule for an empty string. fonoteka works around it in `albumRuleValues` (fonoteka.go `7675d64`). A framework fix (dereference pointers, or apply Laravel's empty-string skip) would cover other models; it changes `required` semantics for `*string` too, so it needs its own change.
- **`tmp/dev-stack/go.log` is appended across `up` runs.** A `grep -c 'status=5..'` over the whole file counts requests from earlier runs. The four 500s from before the empty-format fix were in it until the log was rotated before the Task 4 session. `up` could truncate or rotate the log.
- **`tmp/dev-stack/go.log` is appended across `up` runs.** A `grep -c 'status=5..'` over the whole file counts requests from earlier runs. The four 500s from before the empty-format fix were in it until the log was rotated before the Task 4 session; the session log is kept as `go.log.uat-session-20261011`. `up` could truncate or rotate the log.
- **Orphan artist rows in the Go dev database.** The specs delete the albums they create, but the artists created with them (`E2E Artist`) stay in `fonoteka_go_dev`. Whether PHP removes orphan artists on album delete was not checked.
- **Realtime self-echo guard hides same-user cross-tab edits.** `useRealtimeSync.ts` skips the refresh when `payload.actor.user_id` is the session user, so an edit in a second tab of the same user never refreshes the first tab (PHP and Go alike, UAT finding C). This is frontend design (`app/`, out of scope for D-20); worth a product decision if same-user multi-tab sync is wanted.