[Bug] Self-hosted OSS organization details endpoint returns only owner/invites instead of all members

[eduardofischer]

Describe the bug

In a self-hosted Agenta deployment, the organization details endpoint does not return the full list of actual members.

GET /api/organizations/{organization_id} appears to only include:

the organization owner and invitation-derived entries, but not all existing accepted members of the organization/workspace. As a result, the UI shows only a single member even though more users already belong to the organization.

Setup

Self deployed in Kubernetes using the Helm chart

To Reproduce

1. Run Agenta in a self-hosted OSS deployment.
2. Create an organization and invite multiple users.
3. Have at least one invited user successfully join and become an actual member.
4. Open the organization/workspace member view in the UI, or inspect GET /api/organizations/{organization_id}.
5. Observe that the response only includes the owner and possibly invitation records, instead of the full member list.

Expected behavior

The organization details response should include all actual members of the organization/workspace, not just the owner and invite records.

Screenshots

No response

Agenta SDK Version

v0.95.0

Agenta Image Tag

v0.95.0

Important Context

This was observed in a self-hosted deployment.

The current OSS implementation of GET /api/organizations/{organization_id} appears to build members from:

get_organization_owner(...)
get_project_invitations(...)
and then merges those two lists, without querying all accepted members.

LinkedIn details

https://www.linkedin.com/in/edufischer/

[linear]

AGE-3719

[dosubot]

Hi @eduardofischer! I'm Dosu and I’m helping the agenta team.

Thanks for the detailed bug report! You've correctly identified the root cause.

Looking at the organization_router.py implementation, the GET /api/organizations/{organization_id} endpoint builds the members list from only:

1. The organization owner via db_manager.get_organization_owner()
2. Project invitations via db_manager.get_project_invitations()

The members list is simply concatenated from these two sources with no query for actual accepted organization members.

This appears related to issue #2880, which reports that invited users are created in SuperTokens but not properly linked to the organization in PostgreSQL. The accept_organization_invitation function only marks the invitation as used without creating organization membership records.

The codebase has separate membership models (OrganizationMemberDB, WorkspaceMemberDB, ProjectMemberDB), but the OSS organization endpoint doesn't query these tables.

To fix this, two changes are needed:

1. Add a query for actual organization members from OrganizationMemberDB in the endpoint
2. Fix the invitation acceptance logic to create proper database associations when users accept invitations

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[jp-agenta]

Hi @eduardofischer ,

Thank you reporting this. @mmabrouk is looking into OSS/K8S, today.