feat: add Broadcasts.cancel method

[dielduarte]

Summary

• Adds Resend::Broadcasts.cancel(broadcast_id), calling POST /broadcasts/:id/cancel to cancel a queued or scheduled broadcast.
• Mirrors Emails.cancel's shape (no params, id-only).

Part of the broadcast cancel rollout: resend/resend-monorepo#8126, resend/resend-openapi#85, resend/resend-node#1059, resend/resend-docs#1722, resend/resend-go#144, resend/resend-java#122, resend/resend-php#135, resend/resend-python#250.

Test plan

• ruby -c on touched files — syntax OK
• Could not run the RSpec suite locally (gemspec requires Ruby >= 3.2; this machine only has system Ruby 2.6.10, no version manager available) — relying on CI to verify

🤖 Generated with Claude Code

---

Summary by cubic

Adds Resend::Broadcasts.cancel(broadcast_id) to cancel a queued or scheduled broadcast via POST /broadcasts/:id/cancel. Mirrors Emails.cancel (id-only, no params).

^{Written for commit 5faef89. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 2 files

Confidence score: 5/5

• In spec/broadcasts_spec.rb, the new cancel spec stubs HTTParty.send/resp.body instead of the established Resend::Request#perform seam, which can let the test pass while bypassing the real request path and miss regressions in cancellation behavior—align the stub with allow_any_instance_of(Resend::Request).to receive(:perform) to keep coverage on the intended integration boundary.

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="spec/broadcasts_spec.rb">

<violation number="1" location="spec/broadcasts_spec.rb:157">
P3: The new `cancel` spec stubs `HTTParty.send` (and `resp.body`) instead of following the file's convention of `allow_any_instance_of(Resend::Request).to receive(:perform)`. Because the HTTP call is stubbed away, the test never asserts that `cancel` actually hits `POST broadcasts/:id/cancel` — the expected path, suffix, and verb could all be wrong and the spec would still pass. It effectively only exercises the response-processing plumbing rather than the method being added. Consider stubbing `Resend::Request#perform` like the other specs, or better, asserting on the request path/verb so the cancel route is actually covered.</violation>
</file>

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

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The new cancel spec stubs HTTParty.send (and resp.body) instead of following the file's convention of allow_any_instance_of(Resend::Request).to receive(:perform). Because the HTTP call is stubbed away, the test never asserts that cancel actually hits POST broadcasts/:id/cancel — the expected path, suffix, and verb could all be wrong and the spec would still pass. It effectively only exercises the response-processing plumbing rather than the method being added. Consider stubbing Resend::Request#perform like the other specs, or better, asserting on the request path/verb so the cancel route is actually covered.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At spec/broadcasts_spec.rb, line 157:

<comment>The new `cancel` spec stubs `HTTParty.send` (and `resp.body`) instead of following the file's convention of `allow_any_instance_of(Resend::Request).to receive(:perform)`. Because the HTTP call is stubbed away, the test never asserts that `cancel` actually hits `POST broadcasts/:id/cancel` — the expected path, suffix, and verb could all be wrong and the spec would still pass. It effectively only exercises the response-processing plumbing rather than the method being added. Consider stubbing `Resend::Request#perform` like the other specs, or better, asserting on the request path/verb so the cancel route is actually covered.</comment>

<file context>
@@ -147,6 +147,20 @@
+        "id": "559ac32e-9ef5-46fb-82a1-b76b840c0f7b"
+      }
+      allow(resp).to receive(:body).and_return(resp)
+      allow(HTTParty).to receive(:send).and_return(resp)
+
+      broadcast = Resend::Broadcasts.cancel(resp[:id])
</file context>