docs: update for PR #1060 (group/community metadata, business hours, signal session APIs) - #418
Conversation
…ng APIs from PR #1060
…ng APIs from PR #1060
|
Warning Review limit reached
Next review available in: 40 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
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 |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
|
| Filename | Overview |
|---|---|
| api/signal.mdx | Documents the expanded Signal APIs and clearly explains the state-changing behavior of session inspection. |
| advanced/signal-protocol.mdx | Adds migration and session-inspection guidance to the Signal protocol overview. |
| api/groups.mdx | Documents expanded group metadata, participant details, return types, and member-management methods. |
| api/community.mdx | Documents community discovery, subgroup creation, participant removal, and expanded subgroup metadata. |
Reviews (5): Last reviewed commit: "docs: fix stale ephemeral_expiration/dis..." | Re-trigger Greptile
…ack) Addresses greptile-apps review comment on PR #418: session_info is not a purely read-only inspection when it triggers legacy PN→LID migration.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0465df70d1
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| ### session_info | ||
|
|
||
| Inspect an existing pairwise Signal session without mutating it. |
There was a problem hiding this comment.
Describe session_info's migration side effect
For a PN JID with a known LID mapping and only a legacy PN-addressed session, session_info is not read-only: as the paragraph below explains, it moves the session and identity state into the LID namespace before returning. Describing the method as non-mutating can mislead callers who use it only for inspection but need the original storage namespace preserved.
Useful? React with 👍 / 👎.
| ### Manually migrate a session to LID addressing | ||
|
|
||
| ```rust | ||
| if let Some(info) = client.signal().session_info(&pn_jid).await? { |
There was a problem hiding this comment.
Avoid pre-migrating the manual migration example
When the PN-to-LID mapping is already known, this session_info(&pn_jid) call resolves the address and migrates the legacy PN session itself, as documented earlier in this page. The following migrate_sessions call therefore sees no state left to move, so has_state_changes() is false and the example does not demonstrate or report the advertised manual migration; call migrate_sessions first or use an inspection path that does not migrate.
Useful? React with 👍 / 👎.
…o side effect Addresses chatgpt-codex-connector review comment on PR #418: calling session_info(&pn_jid) before migrate_sessions would already perform the migration as a side effect, making migrate_sessions report no changes. Reordered to migrate first, then inspect the result under the LID address.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: b12d8c3213
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - `limit_sharing_trigger: Option<u32>` - Source trigger for limit-sharing enablement | ||
|
|
||
| <Note> | ||
| `ephemeral_expiration: u32` and `ephemeral_trigger: Option<u32>` were replaced by the single `ephemeral: Option<GroupEphemeralSettings>` field. Migrate reads like `metadata.ephemeral_expiration` to `metadata.ephemeral.as_ref().and_then(|e| e.expiration).unwrap_or(0)`. |
There was a problem hiding this comment.
Update the remaining GroupMetadata timer examples
After documenting the removal of GroupMetadata.ephemeral_expiration, the docs still use that field in guides/sending-messages.mdx:693 and direct readers to it in api/send.mdx:346. Anyone copying the disappearing-message example against the documented v0.6 API gets a compile error, so update those references to read metadata.ephemeral and handle its nested optional expiration.
Useful? React with 👍 / 👎.
| - `lid: Option<Jid>` - Participant's LID JID, when the server includes one | ||
| - `username: Option<CompactString>` - Participant's Meta username, when present | ||
| - `participant_type: ParticipantType` - Participant role (member, admin, or super admin) | ||
| - `details: Option<Box<GroupParticipantDetails>>` - Less-common participant metadata (label, join time, display name, etc.); boxed and only populated when at least one field is present |
There was a problem hiding this comment.
Reconcile display-name guidance with participant details
Adding GroupParticipantDetails::display_name makes this page's existing statements at lines 232 and 1546—that display_name is available only on event-side GroupParticipantInfo and not on GroupMetadata participants—incorrect. Readers can now obtain it through participant.details, so update those notes to describe the nested access path rather than claiming the value is unavailable.
Useful? React with 👍 / 👎.
| - `group_jid` - Group JID | ||
| - `sender_jid` - Sender's JID within the group | ||
|
|
||
| The deletion waits for any in-flight chain mutation (e.g. a concurrent `encrypt_group_message` ratchet advance) to finish before removing the chain, and is flushed to the persistent backend before returning. |
There was a problem hiding this comment.
Remove the stale no-lock warnings for sender-key operations
For callers using the low-level group APIs concurrently, this new guarantee says deletion waits for an encrypt_group_message chain mutation, while the warnings at lines 113 and 151 still say sender-key state is not internally locked. The new guarantee also matches the chain locks documented in advanced/signal-protocol.mdx:703-707 and concepts/architecture.mdx:573-580, so update those warnings to describe the keyed locking contract instead of presenting the operations as categorically unsafe together.
Useful? React with 👍 / 👎.
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
Dismissed because a newer commit was pushed; Greptile will re-review the current head.
Documentation updates reflecting oxidezap/whatsapp-rust#1060 ("feat(core): expand protocol metadata and shared primitives"), which merged to
main.Summary
api/groups.mdxGroupMetadata/GroupInfoResponse—ephemeral_expiration/ephemeral_triggerreplaced byephemeral: Option<GroupEphemeralSettings>(distinguishes "no node" from "explicit 0"), with migration noteGroupMetadatafields (creator/owner identity, versioning, suspension/appeal, safety, labeling, etc.) and newGroupAppealStatusenumGroupParticipantgainslid,username,details(newGroupParticipantDetailstype)promote_participants/demote_participantsnow returnResult<Vec<ParticipantChangeResponse>, GroupError>instead ofResult<(), GroupError>remove_participants_including_linked_groups,update_member_label_with_idguides/group-management.mdxapi/community.mdx/guides/communities.mdxcreate_subgroup(one-call create+link),remove_participants,get_participatingCommunitySubgroupgainscreation,ownerfieldsapi/business.mdxBusinessHoursConfig::open_time/close_timechanged fromu32toOption<u32>api/signal.mdx/advanced/signal-protocol.mdxsession_info,migrate_sessions(+SignalSessionInfo,SignalSessionMigrationtypes),install_prekey_bundle,sender_key_distribution,process_sender_key_distribution,has_sender_key,delete_sender_keySignalError::InvalidInputvariantrotate_signed_pre_keyandvalidate_digest_keyare now public, plus newrefresh_pre_keys_with_count,ensure_pre_keys,add_lid_pn_mappingsapi/contacts.mdxget_profile_picture_with_timeout/ProfilePictureSpec::with_timeoutOut of scope (per standing instructions, changelog entries are human-authored only): no
changelog/ordocs.jsonchanges. A few smaller additive items from the PR (Mex::fetch_reachout_timelock,Voip::reject_call,MessageInfo::timestampJSON serialization) had no corresponding existing doc section to anchor an edit to, so they were left untouched rather than forcing an out-of-place addition.🤖 Generated with Claude Code
Generated by Claude Code
Summary by cubic
Updates the docs for expanded group/community metadata, new Signal session and sender-key APIs, and business-hours type changes. Also clarifies sender-key concurrency, notes that
session_infocan migrate PN→LID state, fixes the manual migration example order, and removes staleephemeral_expiration/display_namereferences across docs (guides andapi/send).New Features
GroupMetadatafields;GroupParticipantaddslid,username,details; newremove_participants_including_linked_groupsandupdate_member_label_with_id(masked-numberdisplay_nameis available viaparticipant.details).create_subgroup,remove_participants,get_participating;CommunitySubgroupaddscreation,owner; new guide walkthroughs.session_info,migrate_sessions,install_prekey_bundle,sender_key_distribution,process_sender_key_distribution,has_sender_key,delete_sender_key; publicrotate_signed_pre_key,validate_digest_key; plusrefresh_pre_keys_with_count,ensure_pre_keys,add_lid_pn_mappings;SignalError::InvalidInput; clarified per-(group_jid, sender_jid)chain locking for safe concurrent encrypt/decrypt.get_profile_picture_with_timeoutandProfilePictureSpec::with_timeout.Migration
GroupMetadata: replaceephemeral_expiration/ephemeral_triggerwithephemeral: Option<GroupEphemeralSettings>.promote_participants/demote_participantsnow returnResult<Vec<ParticipantChangeResponse>, GroupError>.BusinessHoursConfig::open_time/close_timeare nowOption<u32>.Written for commit debc75f. Summary will update on new commits.