Add the oneshot channel implementation by shsms · Pull Request #502 · frequenz-floss/frequenz-channels-python

shsms · 2026-03-05T14:44:27Z

No description provided.

Copilot

Pull request overview

This PR adds a new oneshot channel implementation to the frequenz.channels library, along with a Sender.aclose() abstract method and SenderClosedError exception class. A oneshot channel allows sending exactly one message, after which the sender and receiver are automatically closed.

Changes:

Introduces make_oneshot() factory function and supporting internal _OneShot, _OneShotSender, and _OneShotReceiver classes in a new _oneshot.py module.
Adds an abstract aclose() method to the Sender ABC and a new SenderClosedError exception, with implementations in all existing Sender subclasses (Anycast._Sender, Broadcast._Sender, RelaySender).
Adds tests for the oneshot channel and updates exports and release notes.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
`src/frequenz/channels/_oneshot.py`	New file implementing the oneshot channel with sender, receiver, and factory function
`src/frequenz/channels/_sender.py`	Adds abstract `aclose()` method to `Sender` ABC and new `SenderClosedError` exception class
`src/frequenz/channels/__init__.py`	Exports `make_oneshot` and `SenderClosedError`
`src/frequenz/channels/_anycast.py`	Adds `aclose()` and `SenderClosedError` support to Anycast sender
`src/frequenz/channels/_broadcast.py`	Adds `aclose()` and `SenderClosedError` support to Broadcast sender
`src/frequenz/channels/experimental/_relay_sender.py`	Adds `aclose()` to `RelaySender`, removes redundant `typing.Generic` base class
`tests/test_oneshot.py`	New test file covering oneshot send/receive, close, and error scenarios
`RELEASE_NOTES.md`	Documents the new oneshot channel feature

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

src/frequenz/channels/_anycast.py

src/frequenz/channels/_sender.py

src/frequenz/channels/_oneshot.py

tests/test_oneshot.py

src/frequenz/channels/_broadcast.py

src/frequenz/channels/_sender.py

src/frequenz/channels/_oneshot.py

RELEASE_NOTES.md

Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>

simonvoelcker · 2026-03-05T15:14:16Z

src/frequenz/channels/_oneshot.py

+    def __init__(self) -> None:
+        """Create a new one-shot channel."""
+        self.message: ChannelMessageT | _Empty = _EMPTY
+        self.sent = False


Feels like self.sent could be a derived state of self.message instead? Something like:

@property def sent(self): return self.message is not _EMPTY

That would make the illegal state of these not being in agreement impossible by design.

Or self._channel.event.is_set().

Maybe we can get rid of the redundancy (and possibility of ending with inconsistent state) merging sent, event and message into a asyncio.Queue(maxsize=1).

we also use sent to track if a channel was closed before sending anything. I guess I should change to use a different field for tracking closed, then.

I didn't make any logic changes, just renamed the variable from sent to closed, and now I think it reads much better.

It definitely reads much better with closed. I guess with this all 3 "states" are mostly independent (it can be closed at any time, and the event can be set and drained or not drained, I guess the only dependency is drained can't be true if the event is not set, but that's just a very small dependency).

llucax · 2026-03-05T15:15:56Z

src/frequenz/channels/_oneshot.py

+    def __init__(self) -> None:
+        """Create a new one-shot channel."""
+        self.message: ChannelMessageT | _Empty = _EMPTY
+        self.sent = False


Or self._channel.event.is_set().

llucax · 2026-03-05T15:16:25Z

src/frequenz/channels/_oneshot.py

+from ._sender import Sender, SenderClosedError
+
+
+def make_oneshot(


open_oneshot_channel()? 😬

I feel pretty strongly about this one. This is not a Trio-only thing, open is also used in asyncio, like open_connection().

I would also be up for open_channel() and take the type as an argument somehow, but I guess it will make the interface more complicated (it will need more type parameters) with very little gain.

I'm actually inclined to switching back to channels.oneshot and channels.broadcast.

IMHO, open doesn't work for us at all. For files and networking, open is an idiomatic verb. In both those cases, there is a counterparty or a resource owner, and the idea is to open something to access the other side.

What we are doing is more like creating, because we are creating both sides and the link between them. So to me, Trio's naming is imprecise.

I'd take inspiration from os.pipe, which is so much closer to what we're doing.

That would also match Rust, but I'm ok with make_oneshot, etc. as well, and it also somewhat similar to the Go syntax, where you have to call make for many things, including channels, a bit like the new keyword of C++.

oneshot for me is not an option because it is not a verb. That leaves us with make or open. Let's say we forget about trio and asyncio, I don't understand why you want to introduce an asymmetry between make/close instead of going with open.

And you are opening a channel, the fact that you hide the channel object l, and you close it indirectly by closing all it's sender's or all it's receivers doesn't change the fact that you are opening a channel that needs to be closed.

And I don't get why you want to follow other programming languages naming conventions in python. I really think is not very relevant what rust or go does here.

I think os.pipe is not a good example because it follows very old POSIX naming conventions, not python ones.

I think open_oneshot_channel is the most precise, descriptive and pythonic option.

llucax · 2026-03-05T15:20:35Z

RELEASE_NOTES.md

-<!-- Here goes the main new features and examples or instructions on how to use them -->
+- There's a new `oneshot` channel, which can be created with the `make_oneshot` function, which returns a sender and a receiver.  A single message can be sent using the sender, after which it will be closed.  And the receiver will close as soon as the message is received.
+
+- `Sender`s now have an `aclose`, which can be used to close them.


Suggested change

- `Sender`s now have an `aclose`, which can be used to close them.

- `Sender`s now have an `aclose`, which must be used to close them.

😬

... unless the sender was closed automatically by sending a message through it, I guess? So can would be the correct wording?

I think we want users to close things that are not needed anymore, even though we will take some precaution to cleanup. Because python lacks deterministic or async destructors, cleanup must be done by the users.

I will update the note.

Done, also rephrased a little.

src/frequenz/channels/_oneshot.py

Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>

Copilot AI review requested due to automatic review settings March 5, 2026 14:44

shsms requested a review from a team as a code owner March 5, 2026 14:44

shsms requested review from ela-kotulska-frequenz and removed request for a team March 5, 2026 14:44

Copilot started reviewing on behalf of shsms March 5, 2026 14:45 View session

Copilot AI reviewed Mar 5, 2026

View reviewed changes

shsms force-pushed the oneshot branch 4 times, most recently from 3f0b85a to d8d258f Compare March 5, 2026 15:06

Support closing of Senders

73258cb

Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>

shsms force-pushed the oneshot branch from d8d258f to 176509e Compare March 5, 2026 15:08

simonvoelcker reviewed Mar 5, 2026

View reviewed changes

llucax reviewed Mar 5, 2026

View reviewed changes

simonvoelcker previously approved these changes Mar 5, 2026

View reviewed changes

shsms added 2 commits March 6, 2026 11:11

Add one-shot channel implementation

e44a7ff

Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>

Update release notes

ee35634

Signed-off-by: Sahas Subramanian <sahas.subramanian@proton.me>

shsms dismissed simonvoelcker’s stale review via ee35634 March 6, 2026 10:15

shsms force-pushed the oneshot branch from 176509e to ee35634 Compare March 6, 2026 10:15

		from ._sender import Sender, SenderClosedError


		def make_oneshot(

	- `Sender`s now have an `aclose`, which can be used to close them.
	- `Sender`s now have an `aclose`, which must be used to close them.

Conversation

shsms commented Mar 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

simonvoelcker Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

llucax Mar 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

simonvoelcker Mar 5, 2026 •

edited

Loading

llucax Mar 5, 2026 •

edited

Loading