list_* functions pass the collection type to Page.from_map, so every item parses to an empty wrapper (3.0.0)

[georgeguimaraes]

in workos 3.0.0, every list endpoint that has a dedicated *List wrapper type parses each item with the wrong from_map, so items come back empty and all their real fields are gone.

WorkOS.Page.from_map(body, data_key, cast_item, fetch_next) maps cast_item over each element of body[data_key], so cast_item has to be the element caster. A bunch of the generated list_* functions pass the collection caster instead.

WorkOS.OrganizationMembershipService.list_organization_memberships:

WorkOS.Page.from_map(body, "data", &WorkOS.UserOrganizationMembershipList.from_map/1, fetch_next)

That &UserOrganizationMembershipList.from_map/1 runs against each individual membership map. A single membership has no data/list_metadata keys, so every element comes out as:

%WorkOS.UserOrganizationMembershipList{object: "organization_membership", data: nil, list_metadata: nil}

and id / user_id / organization_id are dropped. Reading membership.organization_id then raises KeyError.

Same in WorkOS.UserManagement.list_users:

WorkOS.Page.from_map(body, "data", &WorkOS.UserList.from_map/1, fetch_next)  # should be &WorkOS.User.from_map/1

Grepping the generated code, the callers passing a *List type are all wrong:

• list_organization_memberships -> UserOrganizationMembershipList (should be UserOrganizationMembership)
• list_users -> UserList (should be User)
• list_invitations -> UserInviteList
• list_user_api_keys -> UserApiKeyList
• group memberships -> GroupList

The ones passing an element type (CORSOriginResponse, UserSessionsListItem, RedirectUri) parse fine, so this looks like a codegen bug: wherever a *List wrapper type exists, the generator wired the wrapper in place of the element type.

Repro: call any of the above with at least one result. Confirmed on 3.0.0 against a stubbed response.

Fix is per function, swap the collection caster for the element one.

[georgeguimaraes]

Confirmed live against the sandbox now (real API call, not a stub). Listing memberships for a real user that has one:

Raw GET /user_management/organization_memberships?user_id=...:

%{
  "object" => "list",
  "data" => [
    %{
      "object" => "organization_membership",
      "id" => "om_...",
      "user_id" => "user_...",
      "organization_id" => "org_...",
      "status" => "active",
      "role" => %{"slug" => "member"},
      "roles" => [%{"slug" => "member"}]
      # ...
    }
  ],
  "list_metadata" => %{"before" => nil, "after" => nil}
}

Same call through WorkOS.OrganizationMembershipService.list_organization_memberships/2, first element of page.data:

%WorkOS.UserOrganizationMembershipList{object: "organization_membership", data: nil, list_metadata: nil}

So the real membership (id/user_id/organization_id all present in the response) gets replaced by an empty list-wrapper, and the fields are gone. membership.organization_id:

** (KeyError) key :organization_id not found in:
    %WorkOS.UserOrganizationMembershipList{object: "organization_membership", data: nil, list_metadata: nil}

workos 3.0.0.

[gjtorikian]

Thanks very much for the report. Given that a lot of this is bunk, I'm opting for a patch release here, rather than the technically correct major release bump.