feat(generated): Add user management operations and models (+1 more)#123
Conversation
Greptile SummaryThis auto-generated PR extends the WorkOS Rust SDK to support Radar-aware authentication flows, adding new request/response models and a new
Confidence Score: 3/5Two public API methods change their return types to stripped-down wrappers, which will cause compilation failures in any downstream crate that uses the returned object's fields. The new Radar SMS challenge endpoint and signal field additions are straightforward and well-tested. However, create_user and create_magic_auth now return types that only carry radar_auth_attempt_id — all User and MagicAuth data fields are gone from the response. Any consumer code that reads the returned user id, email, or magic auth fields will fail to compile. This is faithfully generated from the updated spec, but merging will require coordinated downstream updates and likely a major version release. src/resources/user_management.rs deserves a close look at the create_user and create_magic_auth signatures and their new return types before merging. Important Files Changed
|
| @@ -2141,7 +2193,7 @@ impl<'a> UserManagementApi<'a> { | |||
| &self, | |||
There was a problem hiding this comment.
Breaking return-type change drops all MagicAuth fields
create_magic_auth previously returned Result<MagicAuth, Error>, giving callers the magic auth record (id, email, expiration, etc.). It now returns Result<MagicAuthSendMagicAuthCodeAndReturnResponse, Error>, which only carries Option<radar_auth_attempt_id>. Callers that inspect any field on the returned MagicAuth will fail to compile after upgrading to this version.
Prompt To Fix With AI
This is a comment left during a code review.
Path: src/resources/user_management.rs
Line: 2184-2193
Comment:
**Breaking return-type change drops all MagicAuth fields**
`create_magic_auth` previously returned `Result<MagicAuth, Error>`, giving callers the magic auth record (id, email, expiration, etc.). It now returns `Result<MagicAuthSendMagicAuthCodeAndReturnResponse, Error>`, which only carries `Option<radar_auth_attempt_id>`. Callers that inspect any field on the returned `MagicAuth` will fail to compile after upgrading to this version.
How can I resolve this? If you propose a fix, please make it concise.| .respond_with( | ||
| ResponseTemplate::new(200).set_body_string(include_str!("fixtures/user.json")), | ||
| ) | ||
| .respond_with(ResponseTemplate::new(200).set_body_string("{}")) |
There was a problem hiding this comment.
Round-trip tests inline
"{}" instead of using the newly created fixture files
user_create_response.json (also magic_auth_send_magic_auth_code_and_return_response.json) are both {}, which is identical to what the tests now inline directly. The fixture files are tracked in .oagen-manifest.json and will be maintained by the generator, yet the tests don't use them. Every other round-trip test in this file loads its fixture via include_str!("fixtures/…"). The inconsistency means the fixture files serve no purpose, and future additions to the response schema won't be exercised by these tests.
Prompt To Fix With AI
This is a comment left during a code review.
Path: tests/user_management_test.rs
Line: 3278
Comment:
**Round-trip tests inline `"{}"` instead of using the newly created fixture files**
`user_create_response.json` (also `magic_auth_send_magic_auth_code_and_return_response.json`) are both `{}`, which is identical to what the tests now inline directly. The fixture files are tracked in `.oagen-manifest.json` and will be maintained by the generator, yet the tests don't use them. Every other round-trip test in this file loads its fixture via `include_str!("fixtures/…")`. The inconsistency means the fixture files serve no purpose, and future additions to the response schema won't be exercised by these tests.
How can I resolve this? If you propose a fix, please make it concise.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!
Summary
feat(user_management): Add user management operations and models
SendRadarSmsChallenge.SendRadarSmsChallengeResponse.UrnWorkosOAuthGrantTypeRadarEmailChallengeCodeSessionAuthenticateRequest.UrnWorkosOAuthGrantTypeRadarSmsChallengeCodeSessionAuthenticateRequest.MagicAuthSendMagicAuthCodeAndReturnResponse.UserCreateResponse.ip_addresstoCreateMagicCodeAndReturn.user_agenttoCreateMagicCodeAndReturn.radar_auth_attempt_idtoCreateMagicCodeAndReturn.signals_idtoCreateMagicCodeAndReturn.ip_addresstoCreateUser.user_agenttoCreateUser.signals_idtoCreateUser.signals_idtoAuthorizationCodeSessionAuthenticateRequest.signals_idtoPasswordSessionAuthenticateRequest.radar_auth_attempt_idtoPasswordSessionAuthenticateRequest.radar_auth_attempt_idtoUrnWorkosOAuthGrantTypeMagicAuthCodeSessionAuthenticateRequest.POST /user_management/radar_challenges.fix(user_management): Update user management API surface
UserManagementAuthentication.authenticate.UserManagementUsers.createfromUsertoUserCreateResponse.UserManagementMagicAuth.sendMagicAuthCodeAndReturnfromMagicAuthtoMagicAuthSendMagicAuthCodeAndReturnResponse.Triggered by workos/openapi-spec@71b13e0
BEGIN_COMMIT_OVERRIDE
feat(user_management): Add user management operations and models (#123)
fix(user_management): Update user management API surface (#123)
END_COMMIT_OVERRIDE