Feathers service pagination without explicit `paginate.max` leaves `$limit` unbounded per adapter

Direct Answer

Responsibility for a global $limit ceiling should reside at the Feathers service layer, not in adapter-specific clamping. When paginate.max is omitted, Feathers treats the cap as opt-in and passes the requested $limit through to the underlying adapter. Because Knex, Sequelize, Mongoose, and the memory adapter translate that parameter independently, the effective bound is adapter-, schema-, and release-specific. A uniform service-layer clamp is the only control that behaves consistently across those combinations.

Confirmed Facts vs. Likely Explanation

Confirmed: Feathers pagination is configured per service. If paginate is omitted entirely, many services return an unpaginated array. If default is set but max is omitted, the framework does not impose its own upper bound.

Likely explanation: Any observed ceiling for an oversized $limit comes from the adapter or database, not from Feathers core. That behavior can shift across adapter or core version upgrades, so it must not be treated as a stable contract.

Implementation: Clamp Once at the Boundary

For public or newly scaffolded services, enforce the ceiling in one place before the adapter runs:

1. Create a shared before hook (or a base service) that reads params.query.$limit and clamps it to an application-wide maximum.
2. Set paginate.default and paginate.max explicitly on every service as defense in depth, even when the hook already clamps.
3. Keep the response shape consistent so clients cannot probe for array-versus-paginated behavior.

Adapter-specific clamping alone is sufficient only if you pin exact core and adapter versions and never expose the service to untrusted traffic. For anything public, it is not a uniform contract.

Verification Across Adapters and Releases

Confirm the bound with observable contract tests rather than undocumented internals:

• Seed more rows than the intended ceiling for each deployed adapter.
• Call find with $limit at the ceiling, ceiling+1, and a very large value.
• Assert that the returned data.length is ≤ the ceiling and, when paginated, that the reported limit equals the clamped value.
• Repeat with paginate omitted and with default set but max omitted to record actual behavior for your versions.
• Run these checks in CI against the exact lockfile versions for every service and adapter combination.

Beyond $limit

Clamping $limit is not a security boundary by itself. Also bound $skip, $sort, and broad filters with query validation or allowlists, and pair the hook with authentication and database resource limits. After any core or adapter upgrade, re-run the contract tests because query translation and default pagination can change.