fix(react-dogfood): do not request video ring on audio_call dialer

[aleksandar-apostolov]

💡 Overview

The dialer page (/ring?type=audio_call) hardcodes video: true in its call.getOrCreate({ ring: true, ... }) request regardless of the call type from the URL. The backend rejects ring requests with video: true on call types that have video disabled:

GetOrCreateCall failed with error: "Video is not enabled for this call" (code 4)

This breaks the audio ring flow on getstream.io/video/demos/ring (demo app mmhfdzb5evj2) — and with it every incoming-call E2E test in stream-video-android, including its develop nightly (red since ~Jul 2–6).

Reproduction against the API:

POST /video/call/audio_call/x  {"ring":true,"video":true}   → 400 code 4 "Video is not enabled for this call"
POST /video/call/audio_call/x  {"ring":true,"video":false}  → 200

📝 Implementation notes

One line in DialerPage.tsx: derive the video flag from the call type instead of hardcoding it — video: callType !== 'audio_call'. Non-ring getOrCreate calls are unaffected (the backend only validates the flag on ring requests).

Evidence trail (buddy browser recording showing the error toast, timeline, API probes): stream-video-android run 28856205639 artifacts.

Summary by CodeRabbit

• Bug Fixes
  • Improved call setup so audio-only calls no longer attempt to enable video, preventing call initiation errors in supported cases.
  • Video is now enabled only for call types that support it, making dialing more reliable overall.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 9dab37d6-c3b9-4b78-ad9e-cc54be909b9c

📥 Commits

Reviewing files that changed from the base of the PR and between acde928 and 916e9ca.

📒 Files selected for processing (1)

• sample-apps/react/react-dogfood/components/Ringing/DialerPage.tsx

---

📝 Walkthrough

Walkthrough

The handleRing function in DialerPage was modified so that the ring.video parameter passed to call.getOrCreate is now conditional on callType !== 'audio_call' instead of always being true, with inline comments explaining backend rejection of video for video-disabled call types.

Changes

Ring Video Flag Fix

Layer / File(s)	Summary
Conditional ring.video for audio calls sample-apps/react/react-dogfood/components/Ringing/DialerPage.tsx	ring.video is now set to true only when callType is not 'audio_call', with comments documenting backend rejection of video: true for video-disabled call types.

Estimated code review effort: 1 (Trivial) | ~3 minutes

Possibly related PRs

• GetStream/stream-video-js#2323: Both PRs modify the same handleRing logic in DialerPage.tsx regarding the video/ring.video option for outgoing ringing calls.

Suggested reviewers: santhoshvai

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title is concise and accurately summarizes the main fix for audio_call ring requests.
Description check	✅ Passed	The description covers the overview and implementation notes well, but the ticket and docs sections from the template are missing.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/dialer-audio-call-video-flag

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Bundle size

Built package output. Sizes in KB; delta vs main@acde928.

No significant package size increase vs main.