[snyaggarwal]

Mapping Projects tab sends q to the API instead of filtering in the browser, and pages with the usual pagination controls.

Deploy OpenConceptLab/oclapi2#974 first: an API without it ignores q and the tab would show unfiltered projects.

Closes OpenConceptLab/ocl_issues#2981

🤖 Generated with Claude Code

[snyaggarwal]

Cross-repo review verdict: changes requested before merge.

Findings:

• P2: frontend-first deployment silently shows unfiltered data because the current API ignores q.
• P3: the 240px floor clips the paginator below short viewports; reproduced locally at 1024x300 with the controls ending 54px below the viewport.
• P4: independent count/page requests are serialized, adding avoidable round trips on every user profile.

No security or open-core boundary blocker found. The multi-source slicing algorithm itself is correct: I brute-forced source lengths 0-11, page sizes 1-7, and pages 1-9 with no mismatch.

Verified:

• All 110 frontend tests pass.
• ESLint passes on all five changed files.
• Normal and short-viewport UI behavior checked in the running local app.
• API search test and pylint also pass on the paired oclapi2#974 change.

[snyaggarwal]

Re-review verdict: changes still requested.

Resolved:

• P2 rollout safety: the PR now explicitly requires oclapi2#974 first.
• P4 latency: count and page requests are parallelized without changing pagination results.

Still open:

• P3: fixed-height children still overflow when the available Mapping Projects panel height is smaller than the header plus paginator. On the updated organization profile, 1024x300 leaves the paginator ending at y=304; at 1024x250 the root is 0px, the controls remain at y=303-304, and the 250px document is not scrollable.
• P5: the new 10-second count cache never evicts distinct owners and caches settled/stale responses; use in-flight deduplication or guarded expiry.

No security or open-core boundary blocker.

Re-verified:

• all 110 tests pass;
• ESLint passes on all six changed files;
• pagination boundary sweep passes;
• live responsive behavior checked at normal, 300px, and 250px viewport heights.

[snyaggarwal]

Latest re-review verdict: one P3 remains before merge.

Resolved:

• P5 count cache now deduplicates only in-flight requests and clears on both fulfillment and rejection.

Still open:

• P3 viewport overflow. The new MIN_HEIGHT=160 preserves the panel controls but does not make the fixed profile container scroll. Measured on the updated branch:
  • 1024x300: component y=247-407, paginator y=366-407, document/body scrollHeight=300.
  • 1024x250: component still ends at y=407, document/body scrollHeight=250.
    The paginator is clipped by 107-157px and cannot be scrolled into view.

No other P1-P5 findings or nits. Security and open-core boundary remain clear.

Verification:

• all 110 tests pass;
• ESLint passes on all six changed files;
• pagination boundary sweep passes;
• GitHub lint/test and Snyk checks are green.

[snyaggarwal]

oclweb3-only re-review verdict: one P3 accessibility/responsive edge remains.

The latest change fixes the prior 1024x300 reproduction by allowing the count row and table to collapse while reserving only the 40px paginator. However, when the fixed profile header leaves less than 40px—e.g. an effective 250px CSS viewport at high zoom—the component still forces 40px beyond the available bottom and the unchanged profile ancestors do not provide vertical scrolling. The paginator remains unreachable. The existing P3 thread has the calculation and requested alternatives.

No other P1-P5 findings or nits in head 94bca11.

Verification:

• all 110 tests pass;
• ESLint passes on all six changed files;
• pagination boundary sweep passes;
• GitHub lint/test and Snyk checks are green.

The live page was unavailable because its upstream API was restarting; per the requested scope I did not inspect or operate any non-oclweb3 container.