#1039 Migrate azure/go-amqp to version 1.0.5#1040
#1039 Migrate azure/go-amqp to version 1.0.5#1040cx-joses wants to merge 3 commits intocloudevents:mainfrom
Conversation
c7b277f to
7e99825
Compare
|
Thx for the quick fix! Question: is the reason to bump to |
| type receiver struct{ amqp *amqp.Receiver } | ||
| type receiver struct { | ||
| amqp *amqp.Receiver | ||
| options *amqp.ReceiveOptions |
There was a problem hiding this comment.
question: do we need pointer semantics here (and in the constructors)?
There was a problem hiding this comment.
if you notice the changes on sender file require a pointer since the library used assumes that if nil is passed default is assumed. If in the future the library does the same for the receiver it will be prepared to it. WDYT?
There was a problem hiding this comment.
That is fine, you can always use the copied value with &var - but make a copy of the provided struct (to avoid races/bugs) when calling New...()
There was a problem hiding this comment.
sure, gone back to not using pointer for this case
@embano1 actually it was not supposed to be done. I was thinking of upgrading it all but there is no need and required more changes. |
|
Thx, I still see the bumps though? |
@embano1 I actually upgraded to 1.21 since its the version referred on build steps and others. do you see any issue in doing so? |
IMHO we want to keep
|
understood, you are absolutely right! reverted it all to 1.18 again! thanks |
samples/amqp/receiver/main.go
Outdated
| host, node, opts := sampleConfig() | ||
| p, err := ceamqp.NewProtocol(host, node, []amqp.ConnOption{}, []amqp.SessionOption{}, opts...) | ||
| p, err := ceamqp.NewProtocol(context.Background(), host, node, opts, &amqp.SessionOptions{}, | ||
| &amqp.SenderOptions{}, &amqp.ReceiverOptions{}) |
There was a problem hiding this comment.
would be much nicer if those would not be pointers IMHO
There was a problem hiding this comment.
made it use the struct instead of pointers. thanks
protocol/amqp/v2/sender.go
Outdated
| for _, o := range options { | ||
| o(s) | ||
| } | ||
| func NewSender(amqpSender *amqp.Sender, options *amqp.SendOptions) protocol.Sender { |
There was a problem hiding this comment.
nit: inconsistent with other functions due to pointer
| func NewSender(amqpSender *amqp.Sender, options *amqp.SendOptions) protocol.Sender { | |
| func NewSender(amqpSender *amqp.Sender, options amqp.SendOptions) protocol.Sender { |
There was a problem hiding this comment.
the thing here is that internally there is a default behavior assumed for a nil passing. from there I am assuming a pointer here. is it wrong?
There was a problem hiding this comment.
The Receiver does not use this though (uses struct semantics). Is this expected? If passing nil is valid we
- either need to document this or
- use a functional options pattern where we have
nilas default behavior
samples/amqp/receiver/main.go
Outdated
| host, node, opts := sampleConfig() | ||
| p, err := ceamqp.NewProtocol(host, node, []amqp.ConnOption{}, []amqp.SessionOption{}, opts...) | ||
| p, err := ceamqp.NewProtocol(context.Background(), host, node, opts, amqp.SessionOptions{}, | ||
| amqp.SenderOptions{}, amqp.ReceiverOptions{}) |
There was a problem hiding this comment.
interesting: so we don't need those options, which goes back to my comment on keeping functional options pattern
samples/amqp/sender/main.go
Outdated
| func main() { | ||
| host, node, opts := sampleConfig() | ||
| p, err := ceamqp.NewProtocol(host, node, []amqp.ConnOption{}, []amqp.SessionOption{}, opts...) | ||
| p, err := ceamqp.NewProtocol(context.Background(), host, node, opts, amqp.SessionOptions{}, amqp.SenderOptions{}, |
test/integration/amqp/amqp_test.go
Outdated
| require.NoError(t, err) | ||
| return client, session, addr | ||
| senderOpts = amqp.SenderOptions{} | ||
| require.NotNil(t, senderOpts) |
| require.NotNil(t, senderOpts) | ||
| receiverOpts = &amqp.ReceiverOptions{} | ||
| require.NotNil(t, receiverOpts) | ||
| return client, session, addr, senderOpts, receiverOpts |
There was a problem hiding this comment.
nit: unless needed, don't return pointers but structs
There was a problem hiding this comment.
in the other function you used structs on return
|
any change that this will be merged soon? using the stable go-amqp version would be nice. |
|
@cx-joses are you still down to finish this one? |
I am, I had vacations and another internal topics that made this pending but I will pick it up. Thanks for the notice! |
|
@cx-joses not to put pressure on you :-) but this was identified as one of the ones we'd like to get merged before we cut a new release...soon-ish. If you don't think you'll have time to rebase and address Michael's comments soon please let us know |
|
@duglin what is the timeline you guys are expecting? sorry for the lack of time on this, this is a priority for me also but came in a difficult time! Let's see if I find the time tomorrow to work on this |
|
@cx-joses I don't think there's a firm date, just people getting antsy because of all of the new stuff that's gone in and in particular the release of the CESQL v1.0 spec - which the SDK now supports. |
Signed-off-by: Jose Silva <jose.silva@checkmarx.com>
sure, I will make the comments changes today! |
Signed-off-by: Jose Silva <jose.silva@checkmarx.com>
protocol/amqp/v2/sender.go
Outdated
| for _, o := range options { | ||
| o(s) | ||
| } | ||
| func NewSender(amqpSender *amqp.Sender, options *amqp.SendOptions) protocol.Sender { |
There was a problem hiding this comment.
The Receiver does not use this though (uses struct semantics). Is this expected? If passing nil is valid we
- either need to document this or
- use a functional options pattern where we have
nilas default behavior
5231be7 to
1743a2f
Compare
Signed-off-by: Jose Silva <jose.silva@checkmarx.com>
|
|
||
| // WithConnOpt sets a connection option for amqp | ||
| func WithConnOpt(opt amqp.ConnOption) Option { | ||
| type SendOption func(sender *sender) |
| } | ||
| } | ||
|
|
||
| // WithReceiveOpts sets a receive option for amqp |
There was a problem hiding this comment.
Can you please explain why we need WithReceiverOpts and WithReceiveOpts (also for send)? Is there a way to only have one? These changes complicate the API and I'm having a hard time understanding why we need those very similar options (and I guess new CE users would also be slightly confused?)
There was a problem hiding this comment.
IIUC, this is for the sender/receiver construction, which currently does not support options. Do we need this new functionality at the cost of a more complex user API?
| type ReceiveOption func(receiver *receiver) | ||
|
|
||
| // WithConnOpts sets a connection option for amqp | ||
| func WithConnOpts(opt *amqp.ConnOptions) Option { |
There was a problem hiding this comment.
Since you're using pointer semantics in those options, be careful with races - users might not be aware that you're passing the pointer around (instead of copy) and this could lead to surprises for users. I suggest using value semantic to avoid races and these surprises.
|
@cx-joses what's the status of this one? |
|
@cx-joses can you rebase and fix the conflicts? |
|
@cx-joses are you able, or willing, to rebase this and address the comments? |
Address PR cloudevents#1040 review feedback and improve implementation: **API Simplification:** - Remove unused connOpts and sessionOpts fields from Protocol struct - Remove non-functional WithConnOptions, WithSessionOptions, and WithConnSASLPlain options (they set fields after connection was created) - Connection and session options now passed as direct parameters only - Keep only WithSenderOptions and WithReceiverOptions (functional) **Comprehensive Documentation:** - Add detailed docstrings for Protocol type - Add parameter documentation for all 6 exported constructor functions - Update doc.go examples to show correct API usage - Update MIGRATION.md to remove references to deleted options - Clarify ownership semantics (who closes the connection) **Rationale:** The removed options appeared functional but were actually dead code: - They were applied AFTER connection/session creation - Thus had no effect on actual AMQP behavior - Could confuse users expecting them to work This design aligns with maintainer feedback on PR cloudevents#1040 while maintaining consistency with other SDK protocol bindings (HTTP, Kafka) which use variadic options for protocol-level configuration. All tests pass including Azure Service Bus integration tests.
Changes:
Fixes #1039