Uh oh!
There was an error while loading. Please reload this page.
Fix member-seat double-count; show an upgrade prompt at the cap - #1158
Conversation
Deploying with |
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs | executor-marketing | 4839777 | Commit Preview URL Branch Preview URL | Jun 27 2026, 09:27 PM |
Deploying with |
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs | executor-cloud | 4839777 | Jun 27 2026, 09:27 PM |
0c6b5ab to
cd615c0Compare@executor-js/cli@executor-js/config@executor-js/execution@executor-js/sdk@executor-js/codemode-core@executor-js/runtime-quickjs@executor-js/plugin-file-secrets@executor-js/plugin-graphql@executor-js/plugin-keychain@executor-js/plugin-mcp@executor-js/plugin-onepassword@executor-js/plugin-openapiexecutorcommit: |
Cloudflare previewTorn down — the PR is closed. |
cd615c0 to
aa059b8Compareaa059b8 to
d81b22cCompareA free org with 1 member and 1 pending invite was refused new invites even though the plan allows up to 3 members. The seat count summed listOrganizationMemberships (which returns the invited user as a pending membership) and listInvitations (the same invited user), so every outstanding invite was counted twice and the org hit the limit early. - countSeatsUsed (plans.ts) dedupes: active members plus the larger of pending memberships or pending invitations, never the sum; unit-tested - at the seat limit, "Invite member" opens an upgrade prompt (cloud links it to billing/plans) instead of the invite form, with seat usage shown next to it - the invite endpoint's 403 still carries a human-readable reason, and the dialog surfaces it instead of a generic "try again" - e2e: a free org fills its 3 seats, the upgrade prompt opens, its CTA lands on the plans page, and a direct invite is refused with a reason
d81b22c to
4839777CompareUh oh!
There was an error while loading. Please reload this page.
Greptile SummaryThis PR fixes a WorkOS double-count bug where every outstanding invite was tallied twice (once as a pending organization membership, once as a pending invitation), causing free orgs to be refused new invites below the advertised 3-seat cap. The fix also replaces the generic "Failed to send invitation. Please try again." error with a clear upgrade prompt and a server-provided reason at the limit.
Confidence Score: 4/5Safe to merge. The core seat-counting fix is well-tested and the UI changes are additive with correct guard logic. The The new e2e test ( Important Files Changed
Sequence Diagram%%{init: {'theme': 'neutral'}}%%
sequenceDiagram
participant UI as OrgPage (React)
participant API as inviteMember endpoint
participant WOS as WorkOS
UI->>API: GET listMembers
API->>WOS: listOrgMembers + listPendingInvitations
WOS-->>API: memberships (active + pending) + invitations
API-->>UI: "seats { used: countSeatsUsed(...), granted, unlimited }"
alt "seats.used < seats.granted"
UI->>UI: Invite member opens InviteDialog
UI->>API: POST /members/invite
API->>WOS: reserveMemberSlot check
WOS-->>API: ok
API-->>UI: 200 Invited
else "seats.used >= seats.granted (atSeatLimit)"
UI->>UI: Invite member opens UpgradeDialog
UI->>UI: User clicks Upgrade plan, navigates to /billing/plans
end
note over API: Defense-in-depth if stale UI bypasses prompt
API->>WOS: reserveMemberSlot check
WOS-->>API: over limit
API-->>UI: 403 AccountForbidden with message
UI->>UI: InviteDialog shows server message, not generic retry copy
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
sequenceDiagram
participant UI as OrgPage (React)
participant API as inviteMember endpoint
participant WOS as WorkOS
UI->>API: GET listMembers
API->>WOS: listOrgMembers + listPendingInvitations
WOS-->>API: memberships (active + pending) + invitations
API-->>UI: "seats { used: countSeatsUsed(...), granted, unlimited }"
alt "seats.used < seats.granted"
UI->>UI: Invite member opens InviteDialog
UI->>API: POST /members/invite
API->>WOS: reserveMemberSlot check
WOS-->>API: ok
API-->>UI: 200 Invited
else "seats.used >= seats.granted (atSeatLimit)"
UI->>UI: Invite member opens UpgradeDialog
UI->>UI: User clicks Upgrade plan, navigates to /billing/plans
end
note over API: Defense-in-depth if stale UI bypasses prompt
API->>WOS: reserveMemberSlot check
WOS-->>API: over limit
API-->>UI: 403 AccountForbidden with message
UI->>UI: InviteDialog shows server message, not generic retry copy
Reviews (1): Last reviewed commit: "Fix member-seat double-count; show an up..." | Re-trigger Greptile |
| const submitInvite = async (email: string) => { | ||
| await page.getByRole("button", { name: "Invite member" }).click(); | ||
| const dialog = page.getByRole("dialog"); | ||
| await dialog.waitFor(); | ||
| await page.waitForTimeout(500); | ||
| await dialog.getByPlaceholder("colleague@company.com").fill(email); | ||
| await page.waitForTimeout(800); | ||
| await dialog.getByRole("button", { name: "Send invite" }).click(); | ||
| await dialog.waitFor({ state: "hidden", timeout: 15_000 }); | ||
| }; |
There was a problem hiding this comment.
e2e/AGENTS.md states "Keep it deterministic: no sleeps; wait on conditions." This function has two unconditional waitForTimeout calls (500 ms before filling the input, 800 ms before clicking Send) where condition-based waits would work: wait for the input to be enabled before filling, and wait for the button to be enabled before clicking. The test has 5 waitForTimeout calls in total (lines 66, 68, 81, 94, 98), all of which can silently become either too short on a slow CI machine or waste time on a fast one.
Context Used: e2e/AGENTS.md (source)
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| export const countSeatsUsed = ( | ||
| memberships: ReadonlyArray<SeatMembership>, | ||
| pendingInvitationCount: number, | ||
| ): number => { | ||
| const active = memberships.filter((m) => m.status === "active").length; | ||
| const pendingMembers = memberships.filter((m) => m.status === "pending").length; | ||
| return active + Math.max(pendingMembers, pendingInvitationCount); | ||
| }; |
There was a problem hiding this comment.
Math.max deduplication assumes the two sets always overlap
The fix is correct for the documented WorkOS behavior (every invitation produces exactly one pending membership). However, the Math.max approach undercounts if the two lists ever contain different people simultaneously: e.g., user A is a pending membership whose invitation was already cleared, AND user B has a pending invitation whose membership hasn't appeared yet. In that state pendingMembers = 1, pendingInvitationCount = 1, so max(1, 1) = 1, but 2 seats are actually occupied. A comment documenting that correctness depends on this overlap invariant would make the assumption explicit and help future maintainers.
What
A free org with 1 member and 1 pending invite was refused new invites even though the plan allows up to 3 members, and the refusal showed only "Failed to send invitation. Please try again."
Root cause: seat usage was
listOrganizationMemberships().length + listInvitations().length. WorkOS returns an unaccepted invite as BOTH a pending organization membership AND a pending invitation for the same person, so every outstanding invite was counted twice. A 1-member org with 1 pending invite read as 3 seats used and could not invite a third.Change
countSeatsUsed(plans.ts) dedupes: active members plus the larger of pending memberships or pending invitations, never the sum. Unit-tested inplans.test.ts, including the exact reported case (1 active + 1 pending membership + 1 invitation = 2, not 3).Recording
A free org fills its 3 member seats (each invited person appears as a pending "Invited" member); at the cap, Invite member opens the upgrade prompt, and its CTA lands on the billing plans page.
Notes
@executor-js/emulateso the WorkOS emulator creates a pending membership on invite, matching real WorkOS (without it the emulator only stored an invitation row, so invited users never rendered). The upstream fix is WorkOS: create a pending membership when an invitation is sent emulate#3; drop the patch once executor consumes a publishedemulatewith that behavior. The publish is currently blocked by a separate emulate release-pipeline issue (manifest declares unpublished bundled deps, and CI npm auth fails).