insights-correlations (#22)

Reviewed-on: #22

crates/application/src/watchlist/get_watchlist_for_owner.rs

@@ -9,22 +9,11 @@ use crate::watchlist::deps::{GetWatchlistDeps, GetWatchlistForOwnerDeps};
 use crate::watchlist::get;
 use crate::watchlist::queries::GetWatchlistQuery;
 
-/// Which data source answered a watchlist page request. The former handler
-/// decided this by probing for a local user row — that decision now lives here,
-/// not in `handlers/watchlist.rs`.
 pub enum WatchlistView {
     Local(Paginated<WatchlistWithMovie>),
     Remote(Vec<RemoteWatchlistEntry>),
 }
 
-/// `limit`/`offset` are taken raw, not as a pre-built `PageParams`, on purpose:
-/// they're only validated on the local branch, by delegating to
-/// `watchlist::get::execute` (whose `PageParams::new` call is where the validation
-/// actually happens). The remote branch ignores them entirely, unconditionally
-/// fetching the full federated watchlist. The delegation call below must stay
-/// inside the `if is_local` branch — calling it before the local/remote decision
-/// would turn an out-of-range `limit` into a 400 on a remote owner's page, which
-/// never happened before and must not start happening now.
 pub async fn execute(
     deps: &GetWatchlistForOwnerDeps,
     owner_id: Uuid,
@@ -33,9 +22,6 @@ pub async fn execute(
 ) -> Result<WatchlistView, DomainError> {
     let user_id = UserId::from_uuid(owner_id);
 
-    // Matches the deleted handler's `.map(|u| u.is_some()).unwrap_or(false)`
-    // exactly: a lookup error is treated the same as "no local row", falling
-    // through to the remote arm rather than propagating.
     let is_local = deps
         .user
         .find_by_id(&user_id)
@@ -58,8 +44,6 @@ pub async fn execute(
         .await?;
         Ok(WatchlistView::Local(paginated))
     } else {
-        // Matches the deleted handler's `.unwrap_or_default()`: a federation
-        // lookup error yields an empty list, not a propagated error.
         let entries = deps
             .remote_watchlist
             .get_by_derived_uuid(owner_id)

crates/application/src/watchlist/tests/get_watchlist_for_owner.rs

@@ -44,8 +44,6 @@ async fn watchlist_for_owner_returns_local_when_user_row_exists() {
     let user = b.user_repo.find_by_email(&email).await.unwrap().unwrap();
     let uid = user.id().value();
 
-    // If the local-row decision were wrong and this reached the remote arm, the
-    // panic port below would fail the test instead of silently passing.
     let deps = GetWatchlistForOwnerDeps {
         user: b.user_repo.clone(),
         watchlist: InMemoryWatchlistRepository::new(),
@@ -75,9 +73,6 @@ async fn watchlist_for_owner_returns_remote_when_no_local_row() {
         },
     ]);
 
-    // No user row exists for `owner_id` in this fresh, empty user repo — the
-    // local-vs-remote decision must fall through to the remote arm. The panic
-    // port below proves the local arm is never touched.
     let deps = GetWatchlistForOwnerDeps {
         user: InMemoryUserRepository::new(),
         watchlist: Arc::new(PanicWatchlistRepository),
@@ -97,10 +92,6 @@ async fn watchlist_for_owner_returns_remote_when_no_local_row() {
     }
 }
 
-/// Pins a pre-existing quirk: the old handler validated `limit`/`offset` only on
-/// the local branch (inside `watchlist::get::execute`'s `PageParams::new` call) —
-/// the remote branch never looked at them at all. An out-of-range limit must
-/// still surface as a validation error on the local arm.
 #[tokio::test]
 async fn watchlist_for_owner_local_arm_validates_limit() {
     let b = TestContextBuilder::new();
@@ -126,9 +117,6 @@ async fn watchlist_for_owner_local_arm_validates_limit() {
     ));
 }
 
-/// Same quirk, other direction: an out-of-range limit is silently ignored on the
-/// remote arm, exactly as before — it must not turn into a validation error just
-/// because the use case now owns the branch decision.
 #[tokio::test]
 async fn watchlist_for_owner_remote_arm_ignores_invalid_limit() {
     let owner_id = Uuid::new_v4();