github-starred/better-auth
2
0
Fork 0
mirror of https://github.com/better-auth/better-auth.git synced 2026-05-22 14:21:55 -05:00
Code Issues 2.5k Packages Projects Releases 112 Wiki Activity

[GH-ISSUE #3467] findFullOrganization should not be limited by membershipLimit #9614

New Issue
Closed
opened 2026-04-13 05:10:25 -05:00 by GiteaMirror · 1 comment
GiteaMirror commented 2026-04-13 05:10:25 -05:00
Owner
Copy Link

Originally created by @wottpal on GitHub (Jul 19, 2025).
Original GitHub issue: https://github.com/better-auth/better-auth/issues/3467

Is this suited for github?

  • Yes, this is suited for github

To Reproduce

Currently, findFullOrganization (and findTeamById & listMembers) limit their member queries to membershipLimit (default 100). If there are more valid memberships in the database* this results (a) in an inconsistent state and (b) let's setActiveOrganization calls fail (related: #3466, #3465).

*Potential Reasons:

  • The limit was previously higher and got reduced
  • members where added to the database w/o better-auth

Even though if the argumentation is something like "but we want to never have a state where an organization has more members than membershipLimit", I would respond:

  1. This results in state inconsistencies between DB & API
  2. This limit should be mainly enforced when adding new members via the API
  3. And even If the limitation is decided to be kept, there should be a clear sorting/filtering strategy & documentation on which members to return and which not.

Current vs. Expected behavior

Current: findFullOrganization, findTeamById, and listMembers limit their result based on membershipLimit
Expected: Always take all valid memberships from the database into account

What version of Better Auth are you using?

1.2.12

Provide environment information

n/a

Which area(s) are affected? (Select all that apply)

Backend, Client

Auth config (if applicable)

import { betterAuth } from "better-auth"
export const auth = betterAuth({
  emailAndPassword: {  
    enabled: true
  },
});

Additional context

No response

Originally created by @wottpal on GitHub (Jul 19, 2025). Original GitHub issue: https://github.com/better-auth/better-auth/issues/3467 ### Is this suited for github? - [x] Yes, this is suited for github ### To Reproduce Currently, `findFullOrganization` (and `findTeamById` & `listMembers`) limit their member queries to `membershipLimit` (default `100`). If there are more valid memberships in the database* this results (a) in an inconsistent state and (b) let's `setActiveOrganization` calls fail (related: #3466, #3465). *Potential Reasons: - The limit was previously higher and got reduced - `members` where added to the database w/o better-auth Even though if the argumentation is something like "but we want to never have a state where an organization has more members than `membershipLimit`", I would respond: 1. This results in state inconsistencies between DB & API 2. This limit should be mainly enforced when adding new members via the API 3. And even If the limitation is decided to be kept, there should be a clear sorting/filtering strategy & documentation on **which** members to return and **which not**. ### Current vs. Expected behavior Current: `findFullOrganization`, `findTeamById`, and `listMembers` limit their result based on `membershipLimit` Expected: Always take all valid memberships from the database into account ### What version of Better Auth are you using? 1.2.12 ### Provide environment information ```bash n/a ``` ### Which area(s) are affected? (Select all that apply) Backend, Client ### Auth config (if applicable) ```typescript import { betterAuth } from "better-auth" export const auth = betterAuth({ emailAndPassword: { enabled: true }, }); ``` ### Additional context _No response_
GiteaMirror added the locked label 2026-04-13 05:10:25 -05:00
GiteaMirror commented 2026-04-13 05:10:28 -05:00
Author
Owner
Copy Link

@dosubot[bot] commented on GitHub (Jul 19, 2025):

In Better Auth v1.2.12, findFullOrganization, findTeamById, and listMembers all enforce a hard membershipLimit (default 100) at the plugin configuration level. This limit applies to all queries for organization members, so if your database contains more members than the limit, only the first membershipLimit members are returned. This can cause inconsistencies between the database and API, and may break logic like setActiveOrganization if the active member is not included in the limited result set. There is no built-in way to override or bypass this limit per request, nor is there pagination or a documented sorting/filtering strategy for which members are returned when the limit is hit—the order is determined by the underlying database query. The only workaround in v1.2.12 is to raise the global membershipLimit in your plugin config, but this may not be practical for all use cases citation.

Recent versions (after v1.2.12) have introduced support for making membershipLimit a function, allowing dynamic limits based on organizationId and session context citation. If you need more flexibility, consider upgrading to a version that supports this feature. Otherwise, removing or relaxing the limit would require a code change.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other  Join Discord Share on X

<!-- gh-comment-id:3092304918 --> @dosubot[bot] commented on GitHub (Jul 19, 2025): <!-- Answer --> In Better Auth v1.2.12, `findFullOrganization`, `findTeamById`, and `listMembers` all enforce a hard `membershipLimit` (default 100) at the plugin configuration level. This limit applies to all queries for organization members, so if your database contains more members than the limit, only the first `membershipLimit` members are returned. This can cause inconsistencies between the database and API, and may break logic like `setActiveOrganization` if the active member is not included in the limited result set. There is no built-in way to override or bypass this limit per request, nor is there pagination or a documented sorting/filtering strategy for which members are returned when the limit is hit—the order is determined by the underlying database query. The only workaround in v1.2.12 is to raise the global `membershipLimit` in your plugin config, but this may not be practical for all use cases [citation](https://github.com/better-auth/better-auth/blob/8e4f9b6c6fe9b1d97b7fd6f615e0b120b47e87b0/packages/better-auth/src/plugins/organization/adapter.ts). Recent versions (after v1.2.12) have introduced support for making `membershipLimit` a function, allowing dynamic limits based on organizationId and session context [citation](https://github.com/better-auth/better-auth/pull/3367). If you need more flexibility, consider upgrading to a version that supports this feature. Otherwise, removing or relaxing the limit would require a code change. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/a87c898e-5025-43c7-a16d-512643d1f01f?feedback_type=other)</sup>&nbsp;&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/better-auth/better-auth/issues/3467)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
adapter
astro
awaiting external contributor
blocked
breaking
breaking change
bug
c-devops
core
credentials
database
dependencies
devops
devtools
docs
documentation
duplicate
elysia
enhancement
enterprise
expo
express
fastify
good first issue
help wanted
hono
identity
infra
integration
invalid
javascript
locked
maintenance
need-more-information
needs: info
needs: repro
nextjs
nuxt
oauth
organization
P0
payments
perf
platform
plugin
pull-request
Mirrored from GitHub Pull Request
 question
ready
regression
remix
security
social-provider
solid
stale
svelte
tanstack-start
tracking
version-bump
vue
wontfix
No Label locked
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/better-auth#9614
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?