Retire the standalone browser UI and add a migration owner - #39
Merged
Conversation
The internal JSON API (Api/PublicApi) and the Blazor browse UI (Web) were the standalone-Mediathek-browser product that DR-010 superseded — Sonarr/Radarr drive Krautwatch now, so there is no first-party browse surface. Part 4 (final) of the *arr API-surface plan. - Delete src/Presentation/Api/PublicApi and src/Presentation/Web entirely (~3k lines of dead browse code + its HttpClient). - Add src/Presentation/Migrator — a run-to-completion worker that owns EF migrations and exits. Every DB consumer (newznab + agents) WaitForCompletion it, which removes the old "the API host migrates at startup" coupling and the startup race it implied. - AppHost drops the api/web resources and adds the migrator; slnx + AppHost refs updated. CLAUDE.md architecture/commands refreshed (Blazor removed, EF command no longer points at the deleted Api, Mapperly noted). A genuine *arr config UI (Sonarr/Radarr instances, apikey) is future greenfield work — the retired Web had none of it. ./build.cmd Test green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ChrisonSimtian
added a commit
that referenced
this pull request
Jul 26, 2026
A fresh, purpose-built first-party UI so Krautwatch is usable on its own, without a Sonarr/Radarr instance (the old pre-DR-010 browser was deleted in #39; this is not that). - Presentation/Web: Blazor Server, talks to the Application layer in-process (no HTTP hop). Pages: Home, Search (find crawled episodes → one-click download via AddDownloadByTokenHandler), Activity (live download monitor, auto-refresh every 3s off GetDownloadQueue). Each user action uses a fresh DI scope so Blazor Server's circuit-scoped DbContext can't be used concurrently. - AppHost runs it (WithExternalHttpEndpoints, WaitForCompletion(migrator)); it does not own migrations. slnx + AppHost refs updated. Also fixes a latent fleet-wide DI bug this surfaced: AddApplication registered RunDownloadHandler (needs IDownloadProvider) and AddInfrastructure registered IMessageDispatcher→WolverineDispatcher (needs Wolverine's IMessageBus) for ALL hosts, so dev-time ValidateOnBuild failed in any host without those deps (Web, newznab, migrator, crawl agents). Scoped both to their real consumers: RunDownloadHandler → the Downloader host; IMessageDispatcher → new AddMessageDispatcher() called by the crawl agents. Smoke-tested: the app boots, Home/health/app.css serve 200. ./build.cmd Test green. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ChrisonSimtian
added
the
skip-changelog
ChrisonSimtian
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What & why
The internal JSON API (
Api/PublicApi) and the Blazor browse UI (Web) were the standalone-Mediathek-browser product that DR-010 superseded — Sonarr/Radarr drive Krautwatch now, so there's no first-party browse surface. This is part 4 (final) of the *arr API-surface plan.I confirmed with a full read of
Webfirst: it's 100% browse (Catalog/Shows/EpisodeDetail/Downloads/Search, "MediathekNext" branding, HTTP client to the internal Api) — nothing config-related to salvage. The real *arr config UI (Sonarr instances, apikey) is separate greenfield work.Changes
src/Presentation/Api/PublicApiandsrc/Presentation/Webentirely (~3k lines of dead browse code + itsMediathekApiClient).src/Presentation/Migrator— a run-to-completion worker that owns EF migrations and exits. Every DB consumer (newznab + agents)WaitForCompletion(migrator), which removes the old "the API host migrates at startup" coupling (and the start-order race it implied — agents/newznab previously onlyWaitFor(db)the container, not the schema).api/web, addsmigrator;slnx+ AppHost refs updated.Notes
WaitForCompletion../build.cmd Testgreen (Application 44 / Architecture 8 / Infrastructure 47) — no test touched the deleted projects.Plan complete
Remaining real work: the Downloader agent — consume the enqueued jobs and do the actual raw/ffmpeg pull, the one piece that turns a Sonarr grab into a file on disk.
🤖 Generated with Claude Code