Similar to the problem described in #1115, protocol/nats/v2.Sender requires a subject to be set when calling NewSender or NewSenderFromConn. However, the subject can vary from send-to-send.
Curiously, Sender.Subject is in fact public, as are a surprising number of fields in that package. So a workaround might be to wrap it, add a mutex, and swap it out from send-to-send. However, that seems like a sub-par solution.
Would you be open to allowing the subject to be set for individual Send calls via a context accessor? NewSender and NewSenderFromConn don't appear to validate the subject, so we can set it to an empty value already.
Similar to the problem described in #1115,
protocol/nats/v2.Senderrequires a subject to be set when callingNewSenderorNewSenderFromConn. However, the subject can vary from send-to-send.Curiously,
Sender.Subjectis in fact public, as are a surprising number of fields in that package. So a workaround might be to wrap it, add a mutex, and swap it out from send-to-send. However, that seems like a sub-par solution.Would you be open to allowing the subject to be set for individual Send calls via a context accessor?
NewSenderandNewSenderFromConndon't appear to validate the subject, so we can set it to an empty value already.