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
fix(pubsub): add deadletter and retries handling in the fake pubsub #5320
Conversation
Solves #5319 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for drafting this PR. I had a few minor suggestions but otherwise looks good!
…dead letter policy is set Co-authored-by: Alex Hong <9397363+hongalex@users.noreply.github.com>
if m.deliveries != nil { | ||
deliveries = *m.deliveries | ||
} | ||
s.deadLetterTopic.publish(m.proto.Message, &Message{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here I doubt that I need to use the original message properties (deliveries
and acks
) since the publish
method is not allowing the proto values as well for these properties.
This is about the changes that you suggested around m.proto.DeliveryAttempt
.
Also you can check fake_test.go#382
…oogleapis#5320) * fix(pubsub): add deadletter and retries handling in the fake pubsub server * fix(pubsub): Sync delivery attempt field here before incrementing if dead letter policy is set Co-authored-by: Alex Hong <9397363+hongalex@users.noreply.github.com> * fix(pubsub): delivery attempts to proto as well; typos Co-authored-by: Alex Hong <9397363+hongalex@users.noreply.github.com>
Client
PubSub
Go Environment
go version go1.16.6 darwin/amd64
Description
The PubSub library offers a testing server that is still in beta and therefore does not have all the functionalities.
This ticket is about improving the PubSub testing server to handle correctly Deadletters and retries.
Expected behavior
When a Subscription is created with a DeadLetter and retries configuration, an unacked message is received from the subscription only as many times as specified in the retries configuration.
Actual behavior
When a Subscription is created with a DeadLetter configuration, an unacked message is never sent to deadletter and is received from the subscription indefinitely.