-
Notifications
You must be signed in to change notification settings - Fork 169
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deliver Subject field in Push Consumer Config should not have a default or warn/error about it being empty #1203
Comments
It seem like the Go SDK creates a new inbox if the DeliverSubject field is empty. Going to dig and try to see what async_nats does. It does not seem to use a new_inbox() if nats.rs/async-nats/CHANGELOG.md Line 707 in a1876c4
|
This is the old JS API that uses defaults for everything when calling At the same time, removing I don't like it, but maybe throwing a runtime error that delivery subject cannot be empty is the way to go here. |
Returning an error from |
After doing quite a bit of reading I came to the conclusion that the best option for In any case I would highlight in the crate's docs that This is just my feedback as a new |
@simon-connektica I disagree with the idea of automatically setting the deliver subject and here is the reason: If someone have strick permissions for subjects, and forgets to setup the delivery subject, this consumer will not work properly. However, there already is an error returned:
|
Was this error added after the release of 0.33? I did not get this error in my service. |
This is the error returned by the server. What happened when you tried to create a push consumer without a delivery subject? |
Proposed change
The
deliver_subject
field is required in order for a push consumer to work properly, at least mine was not working properly without it. The issue is thatpull::Config
implementsDefault
and#[serde(default)]
for thedeliver_subject
field. It's really easy to mess up the configuration such as in the code below:Use case
Just making the API more fool proof because it's really easy to miss that this field is required from the docs.
Contribution
I could do it if the changes are deemed worthwhile.
The text was updated successfully, but these errors were encountered: