docs: document accept_video token binding and stop_video semantics (whatsapp-rust#1051) - #434
Conversation
…hatsapp-rust#1051) PR #1051 changed accept_video to take a VideoUpgradeToken (rejecting stale requests with CallError::VideoUpgradeExpired), added the token to CallEvent::VideoStateChanged, narrowed stop_video to only affect our own outbound video, added a 5s auto-cancel for unanswered upgrades, and made the CLI's --video auto-accept upgrades on calls that started as audio. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HaZ6NQMqjh5YMCgL8nXRDT
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 17 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 (1)
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 |
|---|---|
| guides/voip-calls.mdx | Documents all PR #1051 breaking changes accurately: new accept_video(token, source, sink) signature, upgrade_token field on VideoStateChanged, CallError::VideoUpgradeExpired, corrected stop_video semantics, 5-second auto-cancel, and updated CLI --video behavior. Two P2 style issues: anchor link text mismatch in the new Warning, and consecutive Warning callouts that could be merged. No missing or incorrect technical content observed. |
Sequence Diagram
sequenceDiagram
participant Peer as Peer
participant Lib as whatsapp-rust
participant App as Application
Note over Peer,App: Peer-initiated video upgrade
Peer->>Lib: "video UpgradeRequestV2"
Lib->>App: "VideoStateChanged { state: UpgradeRequestV2, upgrade_token: Some(token) }"
App->>Lib: "accept_video(token, camera_source, sink)"
alt token valid
Lib->>Peer: "UpgradeAccept + Enabled stanza"
else token expired or cancelled
Lib->>App: "Err(CallError::VideoUpgradeExpired)"
end
Note over Peer,App: Self-initiated video upgrade
App->>Lib: "start_video(camera_source, sink)"
Lib->>Peer: "UpgradeRequestV2"
alt peer accepts within 5 s
Peer->>Lib: "UpgradeAccept"
Lib->>App: "VideoStateChanged { state: UpgradeAccept }"
else timeout
Lib->>Peer: "UpgradeCancelByTimeout"
Lib->>App: "VideoStateChanged { state: UpgradeCancelByTimeout }"
end
Note over Peer,App: Stopping outbound video
App->>Lib: "stop_video()"
Lib->>App: "ok — outbound plane stopped, peer plane unaffected"
Comments Outside Diff (1)
-
guides/voip-calls.mdx, line 1-4 (link)Missing changelog entry for a breaking SDK change
The repo's documented workflow (
.mintlify/automation and the knowledge base) expects a dated changelog entry underchangelog/for each SDK PR that affects the docs. PR #1051 is a breaking signature change (accept_videogains a required argument;CallEvent::VideoStateChangedgains a new field), yet no entry was added. The PR description says this is "per repo convention," but the repo's own contributor guide describes changelog entries as a required step when updating docs in response to an upstream SDK PR. If the convention has changed, it would be worth a comment inCONTRIBUTING.mdorAGENTS.mdso future contributors have a clear signal.Knowledge Base Used: Changelog
Prompt To Fix With AI
This is a comment left during a code review. Path: guides/voip-calls.mdx Line: 1-4 Comment: **Missing changelog entry for a breaking SDK change** The repo's documented workflow (`.mintlify/` automation and the knowledge base) expects a dated changelog entry under `changelog/` for each SDK PR that affects the docs. PR #1051 is a breaking signature change (`accept_video` gains a required argument; `CallEvent::VideoStateChanged` gains a new field), yet no entry was added. The PR description says this is "per repo convention," but the repo's own contributor guide describes changelog entries as a required step when updating docs in response to an upstream SDK PR. If the convention has changed, it would be worth a comment in `CONTRIBUTING.md` or `AGENTS.md` so future contributors have a clear signal. **Knowledge Base Used:** [Changelog](https://app.greptile.com/oxidezap/-/custom-context/knowledge-base/oxidezap/whatsapp-rust-docs/-/docs/changelog.md) How can I resolve this? If you propose a fix, please make it concise.
Prompt To Fix All With AI
Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
guides/voip-calls.mdx:23
**Anchor link text doesn't match destination**
The link `[Peer initiates](#video-io)` navigates to the `## Video I/O` section heading — not to the `**Peer initiates**` bold paragraph within it, which has no anchor because it isn't a heading. A reader who clicks the link lands at the top of Video I/O and must scroll to locate the relevant paragraph. Consider either changing the link text to `[Video I/O](#video-io)` to match the actual destination, or promoting `**Peer initiates**` to a `###` sub-heading (which would generate its own `#peer-initiates` anchor Mintlify can deep-link to).
### Issue 2 of 3
guides/voip-calls.mdx:22-24
**Two consecutive `<Warning>` callouts**
The new warning is placed immediately after the existing one, producing two consecutive orange/red warning banners at the top of the page. Mintlify renders these as visually identical blocks, so readers may skim past the second. Consider folding the PR #1051 breaking-change note into the existing warning (e.g. as a second sentence or a bullet list item), or placing it as a `<Warning>` immediately before the "Peer initiates" paragraph in the Video I/O section where it's most actionable — that would also resolve the anchor-link issue noted separately.
### Issue 3 of 3
guides/voip-calls.mdx:1-4
**Missing changelog entry for a breaking SDK change**
The repo's documented workflow (`.mintlify/` automation and the knowledge base) expects a dated changelog entry under `changelog/` for each SDK PR that affects the docs. PR #1051 is a breaking signature change (`accept_video` gains a required argument; `CallEvent::VideoStateChanged` gains a new field), yet no entry was added. The PR description says this is "per repo convention," but the repo's own contributor guide describes changelog entries as a required step when updating docs in response to an upstream SDK PR. If the convention has changed, it would be worth a comment in `CONTRIBUTING.md` or `AGENTS.md` so future contributors have a clear signal.
Reviews (1): Last reviewed commit: "docs: document accept_video token bindin..." | Re-trigger Greptile
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| </Warning> | ||
|
|
||
| <Warning> | ||
| [PR #1051](https://github.com/oxidezap/whatsapp-rust/pull/1051) changed `CallHandle::accept_video`'s signature and the shape of `CallEvent::VideoStateChanged` to close a race where a cancelled or superseded video-upgrade request could still attach a camera. If you're upgrading from before this PR, see [Peer initiates](#video-io) below and the `VideoUpgradeToken` field on the event. |
There was a problem hiding this comment.
The link [Peer initiates](#video-io) navigates to the ## Video I/O section heading — not to the **Peer initiates** bold paragraph within it, which has no anchor because it isn't a heading. A reader who clicks the link lands at the top of Video I/O and must scroll to locate the relevant paragraph. Consider either changing the link text to [Video I/O](#video-io) to match the actual destination, or promoting **Peer initiates** to a ### sub-heading (which would generate its own #peer-initiates anchor Mintlify can deep-link to).
Prompt To Fix With AI
This is a comment left during a code review.
Path: guides/voip-calls.mdx
Line: 23
Comment:
**Anchor link text doesn't match destination**
The link `[Peer initiates](#video-io)` navigates to the `## Video I/O` section heading — not to the `**Peer initiates**` bold paragraph within it, which has no anchor because it isn't a heading. A reader who clicks the link lands at the top of Video I/O and must scroll to locate the relevant paragraph. Consider either changing the link text to `[Video I/O](#video-io)` to match the actual destination, or promoting `**Peer initiates**` to a `###` sub-heading (which would generate its own `#peer-initiates` anchor Mintlify can deep-link to).
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!
| <Warning> | ||
| [PR #1051](https://github.com/oxidezap/whatsapp-rust/pull/1051) changed `CallHandle::accept_video`'s signature and the shape of `CallEvent::VideoStateChanged` to close a race where a cancelled or superseded video-upgrade request could still attach a camera. If you're upgrading from before this PR, see [Peer initiates](#video-io) below and the `VideoUpgradeToken` field on the event. | ||
| </Warning> |
There was a problem hiding this comment.
<Warning> callouts
The new warning is placed immediately after the existing one, producing two consecutive orange/red warning banners at the top of the page. Mintlify renders these as visually identical blocks, so readers may skim past the second. Consider folding the PR #1051 breaking-change note into the existing warning (e.g. as a second sentence or a bullet list item), or placing it as a <Warning> immediately before the "Peer initiates" paragraph in the Video I/O section where it's most actionable — that would also resolve the anchor-link issue noted separately.
Prompt To Fix With AI
This is a comment left during a code review.
Path: guides/voip-calls.mdx
Line: 22-24
Comment:
**Two consecutive `<Warning>` callouts**
The new warning is placed immediately after the existing one, producing two consecutive orange/red warning banners at the top of the page. Mintlify renders these as visually identical blocks, so readers may skim past the second. Consider folding the PR #1051 breaking-change note into the existing warning (e.g. as a second sentence or a bullet list item), or placing it as a `<Warning>` immediately before the "Peer initiates" paragraph in the Video I/O section where it's most actionable — that would also resolve the anchor-link issue noted separately.
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!
2 participants
Summary
Updates
guides/voip-calls.mdxfor the breaking VoIP changes merged in whatsapp-rust#1051 ("fix(voip): prevent stale audio-to-video upgrades"):CallHandle::accept_videonow takes aVideoUpgradeTokenas its first argument (wasaccept_video(source, sink), nowaccept_video(request, source, sink)). Documented the new signature in the "Peer initiates" flow and the Call Handle method table.CallEvent::VideoStateChangedgained anupgrade_token: Option<VideoUpgradeToken>field — documented whatNonemeans (auto-resolved transition) and how to passSome(token)through toaccept_video.CallError::VideoUpgradeExpired, returned whenaccept_videois called with a stale/cancelled/superseded token — documented alongside the token.stop_videosemantics narrowed: it now only stops our own outbound video; the peer's plane stays up if they keep sending. Previously documented as a full downgrade to audio-only — corrected.start_videoupgrade (VideoState::UpgradeCancelByTimeout) — documented as a Note near the video-upgrade flows and in the method table.voip-cliexample's--videoflag now auto-accepts a peer's mid-call video upgrade even when the call started as audio-only (previously only for calls that were video from the start) — documented in the CLI subcommand table.No other doc file references
CallError,VideoState,accept_video, orVideoUpgradeToken, soguides/voip-calls.mdxwas the only file needing updates. Changelog entries are intentionally left untouched, per repo convention.Generated by Claude Code
Summary by cubic
Updates the VoIP guide to reflect breaking changes from
whatsapp-rustPR #1051:accept_videonow requires aVideoUpgradeToken,stop_videoonly stops local video, and unanswered upgrades auto-cancel after 5s. Also clarifies the event payload and notes CLI--videoauto-accept behavior.upgrade_tokenfromCallEvent::VideoStateChangedtohandle.accept_video(token, ...).CallError::VideoUpgradeExpiredfor stale/cancelled/superseded tokens.handle.stop_video()as stopping only your outbound video; the peer may keep sending.start_videoto auto-cancel after 5s if the peer doesn’t answer.Written for commit f67a817. Summary will update on new commits.