Add Message.respond() convenience to nats-core#953
Conversation
|
Claude finished @caspervonb's task in 2m 15s —— View job Review
The implementation is correct and the approach mirrors nats.go cleanly. All four One real bug: Two smaller issues are noted in inline comments: the |
| RuntimeError: The message was not dispatched by a connected client. | ||
| """ | ||
| if self.reply is None: | ||
| raise NoReplySubjectError |
There was a problem hiding this comment.
Raising the class directly (raise NoReplySubjectError) is valid Python (it auto-instantiates with no args), but raising an instance is the conventional pattern and matches all other raise sites in this codebase.
| raise NoReplySubjectError | |
| raise NoReplySubjectError() |
| reply: str | None = None | ||
| headers: Headers | None = None | ||
| status: Status | None = None | ||
| _client: Client | None = field(default=None, repr=False, compare=False) |
There was a problem hiding this comment.
With @dataclass(slots=True), _client becomes part of the generated __init__ signature, leaking an internal implementation detail into the public constructor. Any user manually constructing a Message will see it in their IDE autocomplete and help() output.
Consider field(default=None, repr=False, compare=False, init=False) and set it after construction at the call sites:
message = Message(subject=subject, data=payload, reply=reply)
message._client = selfThis keeps the public constructor clean while still populating the field (the slot still exists, so attribute assignment works fine).
With slots=True the field showed up in the generated __init__, leaking an internal detail into autocomplete and help(); populate it by assignment at the dispatch sites instead.
Every reply currently requires
await client.publish(msg.reply, data)plus a manualmsg.reply is not Noneguard.Message.respond()mirrors nats.go'smsg.Respond()and removes the boilerplate from the most common request/reply path.