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
Trial for js.Request #1107
base: main
Are you sure you want to change the base?
Trial for js.Request #1107
Conversation
Signed-off-by: Byron Ruth <b@devel.io>
I'm wondering if we want jetstream Response() to have an Ack. EDIT: just realized that the response is not a stream. I'm not sure about that approach. Mixed approach might be confusing for the users. Response in many cases could be simply lost without any side knowing about it and being able to react. |
In my mind msg.Respond() should work properly here, detect a header field reply that overrides. Not sure if this is what @bruth did or not. |
One thing is we need a deterministic inbox for acks, which possibly needs to be under the $JS.API. So if account A exports JS, the same export/domain should work for the ACKS, otherwise acks execute in the current account's JetStream context. |
Yes that is how it works right now. Essentially, it follows the standard @Jarema You are right, that in order to support the async replies, we need another stream/KV that will auto-delete ask replies are delivered. IMO as an end-user experience it would be most straightforward if that was an internally managed stream.
As it is implemented, the acks shouldn't be affected (server back to publisher, subscriber to consumer/server). The only addition is the subscribe to the inbox and the respond from the subscribe to that inbox subject. |
@bruth yes, we just need to keep it in the radar that cross-account acks are currently difficult and we need a strategy for exporting that as a service from the source account |
Why do you think cross account acks are hard? You have to do multiple service exports but I think they are well understood, and hopefully Helix can provide an easy DX with single click. |
The |
Ah.. now this is connecting the dots. I was going through the ADRs a while back and added support in Python (and have an open docs PR), but he noted, that was not yet implemented in the server? |
The clients future proofed some on the handling for the parsing of the JS.ACK |
Got it.. and by "he", I meant @wallyqs of course. |
I have no intention for this to be merged, but I created a branch so that I could add it to my go.mod for these two experiemental examples request-reply and the actual use case posed in NATS Slack, support for buffering requests in order to auto-scale subscribers (up and down to zero). The link is to the output to observe what it is doing. The code is not well written, but wanted to get something working.
This PR just shows a basic, happy path, implementation of what a
js.Request
might look. In general, this form of request-reply feels a bit awkward and error prone with one stream. I think a nicer option would be to store replies in a KV that then the requester could fetch using an ID (by default the random inbox token associated.. or maybe aMsgId
could be required).In any case, if nothing else, it is a discussion starter..