You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unless my understanding is wrong, all APIs that accept an JSOpt array mean that one could call say AddStream(cfg, nats.APIPrefix("MyPrefix.")) and expect this call to make use of the given prefix. They do not, all those calls use the JS context's prefix that was set when calling JetStream().
If that is the intent (to use the context's prefix), then making possible for users to provide nats.APIPrefix() as an option is wrong since it will create confusion.
If the intent was that the prefix can be specified per API call, then there is a bug which stems from apiSubj() that is based on the context instead of the option that is computed in each API call.
Current code looks like this:
As seen above, the context is based on the computed option (a mix of default and user override), but the api subject is based on the context prefix. A solution would be to change apiSubj() to make it a receiver of *jsOpts and call it wit o:
but again, my issue is that we allow to pass APIPrefix() to the JS calls but we don't use it, which is bad. The following code is not doing what one would expect:
Unless my understanding is wrong, all APIs that accept an JSOpt array mean that one could call say
AddStream(cfg, nats.APIPrefix("MyPrefix."))
and expect this call to make use of the given prefix. They do not, all those calls use the JS context's prefix that was set when callingJetStream()
.If that is the intent (to use the context's prefix), then making possible for users to provide
nats.APIPrefix()
as an option is wrong since it will create confusion.If the intent was that the prefix can be specified per API call, then there is a bug which stems from apiSubj() that is based on the context instead of the option that is computed in each API call.
Current code looks like this:
As seen above, the context is based on the computed option (a mix of default and user override), but the api subject is based on the context prefix. A solution would be to change apiSubj() to make it a receiver of
*jsOpts
and call it wito
:with:
Since I am not sure of the original intent, I wanted first to confirm the expected behavior.
The text was updated successfully, but these errors were encountered: