[Bug] Self-hosted OSS invitations depend on active project and fail unless created from the default project

[eduardofischer]

Describe the bug

In a self-hosted Agenta OSS deployment, organization invitations appear to depend on the project that is active at the time the invitation is created.

If the invite is created while a non-default project is selected, the invited user is unable to sign up / accept the invitation. In practice, invitations only seem to work when they are created from the default project.

This appears to happen because the invitation is created using the current project_id, but later validation/acceptance resolves the project from organization_id and uses the first/default project instead of the project originally used for the invite.

Setup

Self-hosted in Kubernetes using the Helm chart.

To Reproduce

1. Run Agenta in a self-hosted OSS deployment.
2. Create an organization with more than one project.
3. Switch to a non-default project.
4. Invite a new user to the organization/workspace.
5. Open the invitation link and try to sign up / accept the invite with the invited email.
6. Observe that signup or invite acceptance fails.
7. Repeat the same process while the default project is selected.
8. Observe that the invitation works from the default project.

Expected behavior

Invitations should be accepted successfully regardless of which project is active when the invitation is created. The invite flow should not depend on the currently selected project.

Screenshots

No response

Agenta SDK Version

v0.95.0

Agenta Image Tag

v0.95.0

Important Context

This was observed in a self-hosted OSS deployment.

Relevant behavior appears to be that invitation creation uses request.state.project_id, while the invite link includes that project_id, but invite validation/acceptance later resolves a project by organization_id and appears to use the first/default project instead of the project associated with the invitation. This leads to mismatches where invites created from non-default projects fail.

LinkedIn details

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

[linear]

AGE-3720

[dosubot]

Thanks for the detailed bug report! I was able to confirm the root cause you identified.

The Problem: When invitations are created, they store request.state.project_id in the InvitationDB record. However, during acceptance, the OSS code path re-derives the project_id from organization_id using .first() instead of using the project_id that's already passed as a query parameter. This causes a mismatch when validation checks for an invitation matching a specific project_id, token, and email.

Key Code Gap: The acceptance endpoint receives project_id as a query parameter, but doesn't pass it to the service function. The service then re-derives it, returning an arbitrary project instead of the one the invitation was created for.

Related Issues: This appears to be connected to issues #3739 and #2880 which reported similar "Unauthorized" errors during invitation acceptance.

Suggested Fix: Modify api/oss/src/routers/organization_router.py (lines 344-348) to pass the project_id query parameter to accept_organization_invitation, and update the service function to use it directly instead of calling get_project_by_organization_id.

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.