Add test for channel send failure after receiver drop

[leynos]

Summary

• add regression test ensuring mpsc send fails when receiver is dropped before send

Testing

• make fmt
• make lint
• make test

---

https://chatgpt.com/codex/tasks/task_e_68bb304382a08322a683fd877a6e49a6

Summary by Sourcery

Tests:

• Add asynchronous test verifying that sending on an mpsc channel errors after the receiver is dropped

[coderabbitai]

Warning

Rate limit exceeded

@leynos has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 5 minutes and 53 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 5fa6a12 and 933f539.

📒 Files selected for processing (1)

• tests/multi_packet.rs (1 hunks)

Summary by CodeRabbit

• Tests
  • Added a new test to validate behaviour when a receiver is dropped during multi-packet sending, ensuring the sender properly reports failure.
  • Improves confidence in error handling and stability under edge conditions.
  • No changes to user-facing functionality or public APIs.

Walkthrough

Add a new async test validating that sending on an mpsc channel fails after the receiver is dropped. No production code changes; only a test addition in tests/multi_packet.rs.

Changes

Cohort / File(s)	Summary of Changes
Tests tests/multi_packet.rs	Add test multi_packet_send_fails_after_receiver_dropped that creates an mpsc channel (capacity 2), drops the receiver, awaits send on the sender, and asserts it errors.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

Packets queued in a tiny queue,
Receiver bows out, bids adieu.
Sender knocks—no door to pass,
Error returns, like shattered glass.
Test stands guard, crisp and neat,
Channel truths now concrete. ✨

✨ Finishing Touches

• 📝 Generate Docstrings

🧪 Generate unit tests

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch codex/add-test-for-send-failure-after-receiver-drop

---

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

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

This PR adds a regression test to verify that sending on an mpsc channel fails once the receiver is dropped.

File-Level Changes

Change	Details	Files
Introduce regression test for send-after-receiver-drop failure	Added new async test multi_packet_send_fails_after_receiver_dropped Initialized channel, dropped the receiver, and attempted to send a message Asserted that tx.send returns an error when the receiver is gone	tests/multi_packet.rs

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[leynos]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[leynos]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 2f95cc0 and 5fa6a12.

📒 Files selected for processing (1)

• tests/multi_packet.rs (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

**/*.rs

⚙️ CodeRabbit configuration file

**/*.rs: * Seek to keep the cyclomatic complexity of functions no more than 12.

• Adhere to single responsibility and CQRS

• Place function attributes after doc comments.

• Do not use return in single-line functions.

• Move conditionals with >2 branches into a predicate function.

• Avoid unsafe unless absolutely necessary.

• Every module must begin with a //! doc comment that explains the module's purpose and utility.

• Comments and docs must follow en-GB-oxendict (-ize / -our) spelling and grammar

• Lints must not be silenced except as a last resort.

  • #[allow] is forbidden.
  • Only narrowly scoped #[expect(lint, reason = "...")] is allowed.
  • No lint groups, no blanket or file-wide suppression.
  • Include FIXME: with link if a fix is expected.

• Where code is only used by specific features, it must be conditionally compiled or a conditional expectation for unused_code applied.

• Use rstest fixtures for shared setup and to avoid repetition between tests.

• Replace duplicated tests with #[rstest(...)] parameterised cases.

• Prefer mockall for mocks/stubs.

• Prefer .expect() over .unwrap()

• Ensure that any API or behavioural changes are reflected in the documentation in docs/

• Ensure that any completed roadmap steps are recorded in the appropriate roadmap in docs/

• Files must not exceed 400 lines in length

  • Large modules must be decomposed
  • Long match statements or dispatch tables should be decomposed by domain and collocated with targets
  • Large blocks of inline data (e.g., test fixtures, constants or templates) must be moved to external files and inlined at compile-time or loaded at run-time.

• Environment access (env::set_var and env::remove_var) are always unsafe in Rust 2024 and MUST be marked as such

  • For testing of functionality depending upon environment variables, dependency injection and the mockable crate are the preferred option.
  • If mockable cannot be used, env mutations in tests ...

Files:

• tests/multi_packet.rs

🔍 Remote MCP

Here are a few points from Tokio’s documentation that are directly relevant to the new test in tests/multi_packet.rs:

• Sending on a bounded tokio::sync::mpsc::Sender<T> will immediately return an error if the receive half has been closed (i.e. the Receiver has been dropped or close() called). In that case, send(value).await yields Err(SendError(value)).

• The error type is SendError<T> (for the async send method) or TrySendError::Closed (for the immediate try_send method), and in both cases the original value is returned inside the error.
  [::turn4search0::]

• Async tests must be annotated with Tokio’s attribute macro #[tokio::test], which sets up a single-threaded runtime by default so that async fn test bodies can .await.
  [::turn7search0::]

These facts confirm that the test’s use of

let (tx, rx) = mpsc::channel(2);
drop(rx);
assert_matches!(tx.send(1).await, Err(_));

correctly exercises the documented behavior of Tokio’s mpsc channel when the receiver is gone.

🔇 Additional comments (1)

tests/multi_packet.rs (1)

64-71: Assert closed-receiver send behaviour — LGTM

Validate that send errors after dropping the receiver. Doc comment placement before the attribute matches guidelines.