api: mark lib-constructed response/result structs #[non_exhaustive] for 1.0 - #794
Merged
Merged
Conversation
…or 1.0 These structs are returned to consumers and only IsOnWhatsAppResult carried #[non_exhaustive] (the convention exists but was applied to exactly one of ~23). Adding a field to any of the others is a breaking change for downstream (Veloz, ESP32 firmware, whatsapp-ui), so this lands the attribute before 1.0. Scope is limited to structs constructed exclusively within their defining crate, so #[non_exhaustive] (which only restricts other crates) is purely additive: it keeps field reads working and blocks only external struct-literal construction and exhaustive matching of types nobody outside the lib builds. - wacore IQ responses: UserInfo, LidQueryResponse, BusinessProfile, BusinessHours, BusinessHoursConfig, BusinessCategory, GroupInfoResponse, GroupParticipantResponse, ParticipantChangeResponse, GroupParticipatingResponse - whatsapp-rust returns: UploadResponse, SendResult, CreateGroupResult, CreateCommunityResult, CommunitySubgroup, LinkSubgroupsResult, UnlinkSubgroupsResult Deliberately excluded: - Event payload structs (Receipt, ConnectFailure, ...) and MessageSource / DeviceListResponse: defined in wacore but constructed in the whatsapp-rust crate (cross-crate), so #[non_exhaustive] would break the build; they need wacore constructors first (separate follow-up). - SendOptions: users construct it via struct literal, so it needs a builder alongside #[non_exhaustive] (an API-design change, separate follow-up). Verified: whole-workspace --all-targets build and the CI clippy command both pass.
📝 WalkthroughSummary by CodeRabbitRelease Notes
WalkthroughThis PR marks fifteen public struct types across the codebase with ChangesAPI forward compatibility via non_exhaustive
🎯 2 (Simple) | ⏱️ ~8 minutes Possibly Related PRs
Suggested Labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Benchmark Results67 unchanged benchmark(s)
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
wacore/src/iq/usync.rs (1)
502-505:⚠️ Potential issue | 🟠 MajorAdd
#[non_exhaustive]toDeviceListResponse(constructed in wacore)
DeviceListResponseis defined inwacore/src/iq/usync.rsand the response is built there (Ok(DeviceListResponse { ... })), but the struct itself has no#[non_exhaustive]. This breaks consistency with the other usync response types in the same module (which do have#[non_exhaustive]) and undermines the stated exclusion rationale—markDeviceListResponsewith#[non_exhaustive]to avoid downstream breakage before 1.0.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@wacore/src/iq/usync.rs` around lines 502 - 505, DeviceListResponse lacks the #[non_exhaustive] attribute unlike the other usync response types; add #[non_exhaustive] immediately above the pub struct DeviceListResponse declaration so future fields can be added without breaking downstream consumers (the struct contains device_lists: Vec<UserDeviceList> and lid_mappings: Vec<UsyncLidMapping>, and is constructed in this crate, so adding the attribute here is safe and keeps consistency).
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@wacore/src/iq/usync.rs`:
- Around line 502-505: DeviceListResponse lacks the #[non_exhaustive] attribute
unlike the other usync response types; add #[non_exhaustive] immediately above
the pub struct DeviceListResponse declaration so future fields can be added
without breaking downstream consumers (the struct contains device_lists:
Vec<UserDeviceList> and lid_mappings: Vec<UsyncLidMapping>, and is constructed
in this crate, so adding the attribute here is safe and keeps consistency).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 08400e48-2d1d-4cdf-a6a9-eb1374f28502
📒 Files selected for processing (7)
src/features/community.rssrc/features/groups.rssrc/send.rssrc/upload.rswacore/src/iq/business.rswacore/src/iq/groups.rswacore/src/iq/usync.rs
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds
#[non_exhaustive]to the public response/result structs the library returns to consumers. Before this, onlyIsOnWhatsAppResultcarried the attribute (the convention exists but was applied to exactly one of ~23 such types), so adding a field to any of the others is a breaking change for downstream crates (Veloz, ESP32 firmware, whatsapp-ui). This lands the attribute before 1.0, while it is still cheap.Scope and why it is safe
#[non_exhaustive]only restricts construction and exhaustive matching from other crates. I limited the change to structs constructed exclusively within their defining crate (verified: zero struct-literal constructions outside the defining crate), so the attribute is purely additive: field reads keep working, and only external struct-literal construction and exhaustive matching of types nobody outside the lib builds are blocked.UserInfo,LidQueryResponse,BusinessProfile,BusinessHours,BusinessHoursConfig,BusinessCategory,GroupInfoResponse,GroupParticipantResponse,ParticipantChangeResponse,GroupParticipatingResponseUploadResponse,SendResult,CreateGroupResult,CreateCommunityResult,CommunitySubgroup,LinkSubgroupsResult,UnlinkSubgroupsResultDeliberately excluded (separate follow-ups)
Receipt,ConnectFailure, ...) plusMessageSourceandDeviceListResponse: defined in wacore but constructed in the whatsapp-rust crate (cross-crate), so#[non_exhaustive]would break the build. They need wacore-side constructors first.SendOptions: users construct it via struct literal, so it needs a builder alongside#[non_exhaustive](an API-design change), not a one-line attribute.Verification
Whole-workspace
--all-targetsbuild passes (this compiles every crate's tests, so any cross-crate exhaustive-match break would have surfaced), and the exact CI clippy command (cargo clippy --all-targets -- -D warnings) passes. No behavior change.