feat(media): support ContextInfo in media options

[arsa0x]

Summary

Add an optional context_info field to all media option structs and forward it to the generated media message.

Why

This enables creating quoted/reply media messages directly through the helper API without manually modifying the generated protobuf.

Breaking changes

None.

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• New Features

  • Media messages now support carrying additional context information for images, videos, documents, and audio.
  • Status image and video sending now use default option handling for unspecified settings, keeping behavior consistent while simplifying setup.

• Bug Fixes

  • Improved media message construction so provided context details are preserved and included when sending.

Walkthrough

Look, this is straightforward, and things need to work right. context_info: Option<Box<wa::ContextInfo>> is added to ImageOptions, VideoOptions, DocumentOptions, and AudioOptions in src/media.rs, and wired into their message builders. Status::send_image/send_video now use ..Default::default() instead of explicit None fields.

Changes

Context Info Support

Layer / File(s)	Summary
Media options and builder wiring src/media.rs	New public context_info field added to ImageOptions, VideoOptions, DocumentOptions, AudioOptions; wired into image_message, video_message, document_message, audio_message; two new tests verify context_info propagation for image and video messages.
Status method simplification src/features/status.rs	send_image and send_video option literals now use ..Default::default() instead of explicitly setting mimetype/gif_playback to None.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• oxidezap/whatsapp-rust#764: Directly related refactor of Status::send_image/send_video to build typed media options via high-level builders.

Suggested labels: api-design

We shipped a field, tight and clean,
Context flows through, sharp and lean.
Defaults now handle what was spelled out plain,
Tests confirm it—no room for pain.
Move fast, ship value, this is the way. 🚀

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main change: adding ContextInfo support to media options.
Description check	✅ Passed	The description accurately summarizes the context_info field addition and its purpose.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
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 unit tests (beta)

• Create PR with unit tests

---

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.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/media.rs (1)

21-64: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Look, adding fields to public structs is like changing the News Feed algorithm — people notice.

context_info is added as a plain public field across four structs. Since none of them appear to be #[non_exhaustive], any downstream consumer using an exhaustive struct literal instead of ..Default::default() breaks on upgrade. Given this crate is pre-1.0 and prior precedent here tolerates breaking API changes without shims, this is likely acceptable — but worth a conscious call rather than an accident.

♻️ Consider marking these Options structs non_exhaustive going forward

+#[non_exhaustive]
 pub struct ImageOptions {
     ...
 }

Based on learnings: for this repo (pre-1.0, e.g. 0.6.0), "public API renames... are allowed without requiring a deprecated compatibility shim, per the crate's versioning policy" — the same tolerance likely applies to additive breaking changes like this one.

🤖 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 `@src/media.rs` around lines 21 - 64, The new public `context_info` fields on
`ImageOptions`, `VideoOptions`, `DocumentOptions`, and `AudioOptions` are an
additive breaking API change for exhaustive struct literals. If this change is
intended, make that contract explicit by marking these option structs as
`#[non_exhaustive]` (or otherwise document the breaking change) so downstream
users know to construct them with `..Default::default()`. Keep the update
aligned with the existing public option types in `src/media.rs` and the crate’s
pre-1.0 API policy.

Source: Learnings

🤖 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.

Inline comments:
In `@src/media.rs`:
- Around line 246-279: Add parity test coverage for the new context_info wiring
in document_message and audio_message. Mirror the existing
image_maps_context_info and video_maps_context_info tests by creating
document_maps_context_info and audio_maps_context_info that build messages via
document_message and audio_message with DocumentOptions and AudioOptions
containing Some(ContextInfo), then assert the resulting document_message and
audio_message payloads preserve context_info.

---

Outside diff comments:
In `@src/media.rs`:
- Around line 21-64: The new public `context_info` fields on `ImageOptions`,
`VideoOptions`, `DocumentOptions`, and `AudioOptions` are an additive breaking
API change for exhaustive struct literals. If this change is intended, make that
contract explicit by marking these option structs as `#[non_exhaustive]` (or
otherwise document the breaking change) so downstream users know to construct
them with `..Default::default()`. Keep the update aligned with the existing
public option types in `src/media.rs` and the crate’s pre-1.0 API policy.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository UI (base), Organization UI (inherited)

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: f628fa2e-2525-4d1f-b5e4-684608a5ba0c

📥 Commits

Reviewing files that changed from the base of the PR and between 4ac1c81 and 7bacbb4.

📒 Files selected for processing (2)

• src/features/status.rs
• src/media.rs

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/media.rs">

<violation number="1" location="src/media.rs:80">
P3: Tests for `context_info` mapping were added for `image_message` and `video_message`, but `document_message` and `audio_message` received the same wiring without corresponding test coverage. Add parity tests (e.g., `document_maps_context_info` and `audio_maps_context_info`) so a future refactor can't silently drop the field on these message types.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[jlucaso1]

@arsa0x thanks <3

[codspeed-hq]

Merging this PR will not alter performance

✅ 176 untouched benchmarks
⏩ 6 skipped benchmarks¹

---

_{Comparing arsa0x:feat/media-context-info (7bacbb4) with main (4ac1c81)}

Footnotes

1. 6 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩