2 Commits (048e4e85d5ceb6bbb9f6a6d2b2efbc259cc331ff)

Author	SHA1	Message	Date
Broque Thomas	cc44254bf9	Personalized playlist pipeline: auto-sync discover-page playlists ... Follow-up to the personalized-playlists standardization PR. New `personalized_pipeline` automation action syncs selected discover- page playlists (Hidden Gems / Discovery Shuffle / Time Machine / Genre / Daily Mix / Fresh Tape / The Archives / Seasonal Mix) to the active media server + queues missing tracks for download. Same pattern as the existing mirrored `playlist_pipeline` but two phases instead of four — no REFRESH (no external source to re-pull) and no DISCOVER (manager-backed snapshots are already metadata- matched). Pipeline shape: SNAPSHOT → SYNC → WISHLIST Where SNAPSHOT either reads the persisted track list from `PersonalizedPlaylistManager` (default) or refreshes it first when `refresh_first=true` (cron use case: regenerate Hidden Gems nightly and sync the fresh set). Shared helper extraction: PHASE 3 (SYNC loop) + PHASE 4 (WISHLIST tail) lifted out of mirrored `playlist_pipeline` into `core/automation/handlers/_pipeline_shared.py` as `run_sync_and_wishlist(deps, automation_id, playlists, sync_one_fn, sync_id_for_fn, ...)`. Both pipelines call it. Mirrored injects `auto_sync_playlist` as the per-playlist sync function; personalized injects a thin wrapper that launches `_run_sync_task` directly with a pre-built tracks_json. Same sync-state polling / progress emission / status counting / wishlist trigger logic — 0 duplication. Files added: - core/automation/handlers/_pipeline_shared.py - core/automation/handlers/personalized_pipeline.py - tests/automation/test_handlers_personalized_pipeline.py Files changed: - core/automation/handlers/playlist_pipeline.py: PHASE 3+4 replaced with shared helper call (~100 lines deleted, 1 helper invocation added; behavior identical). - core/automation/deps.py: new `build_personalized_manager` field (lazy builder so the pipeline gets a fresh PersonalizedPlaylistManager per run). - core/automation/handlers/__init__.py + registration.py: register `personalized_pipeline` action with the shared `pipeline_running` guard so it can't overlap mirrored. - core/automation/blocks.py: new `personalized_pipeline` block declaration with config_fields (kinds multi-select, refresh_first, skip_wishlist). - web_server.py: thread `_build_personalized_manager` into AutomationDeps construction. - All 5 automation test fixtures: `_build_deps` adds `build_personalized_manager=lambda: None` stub. - tests/automation/test_handler_registration.py: EXPECTED_ACTION_NAMES + EXPECTED_GUARDED_ACTIONS gain `personalized_pipeline`. Trigger schema: { "_automation_id": "...", "kinds": [ {"kind": "hidden_gems"}, {"kind": "time_machine", "variant": "1980s"}, {"kind": "seasonal_mix", "variant": "halloween"} ], "refresh_first": false, "skip_wishlist": false } Tests (14 new, 178 automation total): - _track_to_sync_shape: basic shape, source ID fallback chain, no-id returns empty string - empty config / non-list kinds / empty kinds list all return error + clear pipeline_running flag - _build_payloads_for_kinds: skips invalid entries, skips kinds with no tracks, refresh_first vs ensure dispatch, payload shape + sync_id format, manager exception swallowed continues - _sync_personalized_playlist: launches background thread + returns status='started' - happy path: stubbed sync_states drives helper to completion, flag cleaned up Full suite: 3383 passed. Note: the trigger UI block declares config_fields but the frontend doesn't yet render the `personalized_playlist_select` multi-select type — usable today via API; polished UI ships in a follow-up frontend PR.	2 weeks ago
Broque Thomas	e140da117a	Extract automation handlers (4/3 — finish): progress callbacks + scan-completion emitter ... Cleans up the four remaining inline callbacks at the bottom of `web_server._register_automation_handlers` so the function is now purely deps-construction + register_all + a logger.info line. Lifted: - `_progress_init`, `_progress_finish`, `_record_automation_history`, and `_on_library_scan_completed` -> core/automation/handlers/progress_callbacks.py Each is a top-level function that takes deps as a parameter; the engine sees thin lambdas through `register_progress_callbacks` / `register_library_scan_completed_emitter` (called from `register_all`). Two new deps fields: - `init_automation_progress` (delegates into the live progress tracker) - `record_progress_history` (delegates into _auto_progress.record_history) 12 new boundary tests in tests/automation/test_progress_callbacks.py pin every shape: - progress_init forwards to init_automation_progress - progress_finish skips when handler manages its own progress (prevents double-emit of finished status) - progress_finish: completed -> finished/Complete/success; error -> error/Error/error; msg falls through error -> reason -> status -> 'done' - record_history threads the live db into the recorder - on_library_scan_completed: no engine = noop, server type taken from web_scan_manager._current_server_type, defaults to 'unknown' - register_library_scan_completed_emitter: no scan manager = noop, registered callback emits the right event when invoked 3256 tests pass, no regression. Final state of `_register_automation_handlers`: - Was: 1530 lines, 21 nested closures + 4 progress callbacks - Now: ~50 lines, builds AutomationDeps and calls register_all web_server.py: 34,220 -> 34,187 lines (-33 net, -1,406 across the whole branch).	2 weeks ago