Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Torznab multi-category domain and Other(8000) coverage

  • Status: Accepted
  • Date: 2026-02-25
  • Context:
    • Motivation: ERD_INDEXERS acceptance item 580 required explicit validation that Torznab category behavior matches ERD rules for category-to-domain mapping, especially multi-category requests and the Other (8000) catch-all behavior.
    • Constraints:
      • Runtime DB behavior must be validated through stored procedures.
      • Existing Torznab feed mapping already emits category IDs from tracker mapping, but search request creation also needs direct tests for effective domain derivation when torznab_cat_ids are provided.
      • Changes must pass just ci and just ui-e2e.
    • Dependency rationale:
      • No new dependencies were added.
      • Alternative considered: add app-layer mocks around domain mapping. Rejected because ERD behavior is owned by stored procedures and must be tested at that boundary.
  • Decision:
    • Added stored-proc tests in crates/revaer-data/src/indexers/search_requests.rs:
      • search_request_create_torznab_other_category_keeps_unrestricted_domain
      • search_request_create_torznab_multi_category_yields_multi_domain_scope
    • The tests verify:
      • cat=8000 keeps effective_media_domain_id unset (NULL), preserving catch-all behavior.
      • Multi-domain category input (2000 + 5000) keeps effective_media_domain_id unset and preserves effective category rows, matching ERD multi-domain semantics.
    • Updated ERD_INDEXERS_CHECKLIST.md item 580 to complete.
  • Consequences:
    • Positive outcomes:
      • Stored-proc behavior for Torznab category domain narrowing now has explicit regression coverage for the highest-risk acceptance paths.
      • Checklist state is synchronized with tested behavior.
    • Risks or trade-offs:
      • Coverage focuses on request creation semantics; future behavior changes in search execution filtering still require dedicated acceptance tests.
  • Follow-up:
    • Test coverage summary:
      • just ci passes, including new stored-proc tests.
      • just ui-e2e passes.
    • Observability updates:
      • No telemetry schema or span changes were needed in this step.
    • Risk and rollback:
      • Rollback path is low risk: revert the added tests and checklist/ADR updates if needed.
    • Review checkpoints:
      • Continue Phase 12 acceptance items after 580, starting with rate-limit default/enforcement behavior.