fix(security): push analytics tenant isolation into repository query

[seonghobae]

Objective

Reconcile the tenant-scoped list-query semantic from stale descendant #268 directly on current protected main and adopt it in analytics so KPI reads never request the global conversion-job inventory and filter ownership afterward.

Fresh exact state — 2026-08-10

• exact source head: 4eeba73d70db172e44062891c01273efc4109d93;
• independently resolved protected main: 55d7ae8647208e301f282350f076eeddaba61d11;
• clean current-base slice: four changed files, six commits, zero commits behind protected main;
• exact-head CI 31401293063: success;
• exact-head Security Scan 31401293204: success;
• exact-head SAST Semgrep 31401293014: success;
• exact-head fuzz 31401293142: success;
• authoritative Maven verification on the exact source head ran 500 tests with 0 failures, 0 errors and 0 skips; all JaCoCo coverage checks and public Javadocs passed;
• no unresolved review threads and no formal reviews at the latest direct refetch;
• automated checks/statuses are evidence, never qualifying independent approval.

Test-first evidence

RED

Test-only head 0a5ff205b550e2435c4b9267dbc224a2f30e1f02 introduced a focused controller boundary regression before production changes. Exact-head CI 31400542789 checked out that exact SHA and failed during Maven test compilation because protected main did not expose ConversionJobRepository.findAllByTenantId(String). The compiler reported the missing method at all three deliberate test references. Maven merge compatibility and fuzz failed at the same first boundary; buyer-readiness script tests remained green. This established that protected main still required a global inventory read for KPI calculation.

GREEN

Current head adds a fail-closed repository contract whose default returns an empty list rather than falling back to global findAll(). The process-local adapter overrides it with a tenant predicate and rejects missing/blank tenant identifiers. AnalyticsController now passes the authenticated tenant directly into findAllByTenantId(...) and no longer materializes global job inventory.

Focused tests prove:

• analytics calls the storage-scoped tenant query and never global findAll();
• authorization failure occurs before either repository query;
• the interface default fails closed without global fallback;
• the in-memory adapter rejects null/blank tenant identifiers, normalizes surrounding whitespace and returns only owned jobs.

Exact-head CI also proves synthetic-merge compatibility, packaging, the complete Java test suite, exact owned coverage and public Javadocs. Security Scan, Semgrep and fuzz are GREEN on the unchanged exact head.

Scope boundary

This is a deliberate current-base reconciliation of one valuable #268 semantic plus issue #326 analytics adoption. It does not copy #268's stale ancestry or claim the whole descendant is reconciled. Immutable identifier/tombstone behavior, scoped retry/mutation, durable deletion receipts/recovery, audit pseudonymization and generation fencing remain separate semantics to preserve or reimplement deliberately. It is path-disjoint from #341's administrative delete endpoint and from #338/#339 KPI formula/ledger semantics.

Merge gate

Move to Ready for ordinary independent review. Keep this exact head unchanged. Merge or auto-merge may complete only after live protection still sees all applicable required checks passing, zero valid unresolved findings, and any required qualifying independent non-author approval. Automated evidence is not approval.

[coderabbitai]

Warning

Review limit reached

@seonghobae, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 40 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2d7eb5d6-ee2c-4e0e-a70b-053345903dd4

📥 Commits

Reviewing files that changed from the base of the PR and between 55d7ae8 and 4eeba73.

📒 Files selected for processing (4)

• src/main/java/com/clearfolio/viewer/controller/AnalyticsController.java
• src/main/java/com/clearfolio/viewer/repository/ConversionJobRepository.java
• src/main/java/com/clearfolio/viewer/repository/InMemoryConversionJobRepository.java
• src/test/java/com/clearfolio/viewer/controller/AnalyticsTenantQueryBoundaryTest.java

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}