Skip to content
This repository has been archived by the owner on Jan 19, 2022. It is now read-only.

Adding original message to the throwble for Pub/Sub publish failures. #2020

Merged
merged 6 commits into from
Nov 11, 2019

Conversation

sateekot
Copy link
Contributor

@sateekot sateekot commented Nov 7, 2019

Adding original message to Future provided by Publisher if any failures to publish events to Pub/Sub.

@pivotal-issuemaster
Copy link

@sateekot Please sign the Contributor License Agreement!

Click here to manually synchronize the status of this Pull Request.

See the FAQ for frequently asked questions.

@pivotal-issuemaster
Copy link

@sateekot Thank you for signing the Contributor License Agreement!

@codecov
Copy link

codecov bot commented Nov 7, 2019

Codecov Report

Merging #2020 into master will decrease coverage by 7.95%.
The diff coverage is 87.5%.

Impacted file tree graph

@@             Coverage Diff              @@
##             master    #2020      +/-   ##
============================================
- Coverage     80.44%   72.48%   -7.96%     
+ Complexity     2120     1885     -235     
============================================
  Files           243      244       +1     
  Lines          6907     6913       +6     
  Branches        710      710              
============================================
- Hits           5556     5011     -545     
- Misses         1056     1574     +518     
- Partials        295      328      +33
Flag Coverage Δ Complexity Δ
#integration ? ?
#unittests 72.48% <87.5%> (ø) 1885 <1> (+1) ⬆️
Impacted Files Coverage Δ Complexity Δ
...pubsub/core/publisher/PubSubPublisherTemplate.java 86.2% <100%> (+1.02%) 6 <0> (ø) ⬇️
...cloud/gcp/pubsub/core/PubSubDeliveryException.java 75% <75%> (ø) 1 <1> (?)
...a/spanner/repository/query/SpannerQueryMethod.java 0% <0%> (-100%) 0% <0%> (-6%)
...ository/config/FirestoreRepositoriesRegistrar.java 0% <0%> (-100%) 0% <0%> (-3%)
...sitory/support/FirestoreRepositoryFactoryBean.java 0% <0%> (-100%) 0% <0%> (-4%)
...pository/support/FirestoreQueryLookupStrategy.java 0% <0%> (-100%) 0% <0%> (-2%)
...figure/config/GcpConfigBootstrapConfiguration.java 0% <0%> (-100%) 0% <0%> (-2%)
...restore/repository/query/FirestoreQueryMethod.java 0% <0%> (-100%) 0% <0%> (-2%)
...ository/config/DatastoreRepositoriesRegistrar.java 0% <0%> (-100%) 0% <0%> (-3%)
...epository/config/SpannerRepositoriesRegistrar.java 0% <0%> (-100%) 0% <0%> (-3%)
... and 54 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 13d06ff...a1f9442. Read the comment docs.

Copy link
Contributor

@meltsufin meltsufin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for putting together the PR!
I just have one suggested change.
BTW this is for #2003

@@ -103,7 +106,10 @@ public void setMessageConverter(PubSubMessageConverter pubSubMessageConverter) {
@Override
public void onFailure(Throwable throwable) {
LOGGER.warn("Publishing to " + topic + " topic failed.", throwable);
settableFuture.setException(throwable);
Message<?> originalMessage = MessageBuilder.withPayload(pubsubMessage).build();
MessageHandlingException messageHandlingException = new MessageHandlingException(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use MessageDeliveryException instead please?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I wouldn't do that.
I mean we are good to have a PubSubDeliveryException as an extension of the PubSubException.
My point is to not wrap a PubsubMessage into a Message<?>: an original request is not Spring Messaging.
So, let's not abuse non-related API, but we definitely can borrow an idea! 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your comments. I have updated the code accordingly. Can you please check the updated commit.

Copy link
Contributor

@artembilan artembilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your name, please, into the modified classes.
And let's consider to mention such a feature in docs somehow!

Thanks

@@ -103,7 +106,10 @@ public void setMessageConverter(PubSubMessageConverter pubSubMessageConverter) {
@Override
public void onFailure(Throwable throwable) {
LOGGER.warn("Publishing to " + topic + " topic failed.", throwable);
settableFuture.setException(throwable);
Message<?> originalMessage = MessageBuilder.withPayload(pubsubMessage).build();
MessageHandlingException messageHandlingException = new MessageHandlingException(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, I wouldn't do that.
I mean we are good to have a PubSubDeliveryException as an extension of the PubSubException.
My point is to not wrap a PubsubMessage into a Message<?>: an original request is not Spring Messaging.
So, let's not abuse non-related API, but we definitely can borrow an idea! 😄

@sateekot
Copy link
Contributor Author

sateekot commented Nov 8, 2019

@artembilan I am not sure how to update this feature in docs, Can you please give me some pointers.

Copy link
Contributor

@meltsufin meltsufin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docs could be updated in pubsub.adoc. If you don't feel comfortable doing it, it's ok to create an issue to do it in a separate PR.

this.failedMessage = pubsubMessage;
}

public PubSubDeliveryException(PubsubMessage pubsubMessage, Throwable cause) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's just keep the one constructor we currently use. We can always add more. Otherwise, we have all this code that's missing coverage.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed constructors.

}

@Override
public String toString() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't typically overwrite the toString() for exceptions. Who is going to call this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we don't override toString(), the newly added test case is failing as we are checking the message in the exception.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That has to be done with the cast and that getFailedMessage().

So, yes +1 to remove this toString()

Copy link
Contributor

@artembilan artembilan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is some review from me.

Nothing critical - a general solution is OK.

}

@Override
public String toString() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That has to be done with the cast and that getFailedMessage().

So, yes +1 to remove this toString()

private final PubsubMessage failedMessage;

public PubSubDeliveryException(PubsubMessage pubsubMessage, Throwable cause) {
super(null, cause);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to provide some message into an exception anyway.
I mean that required by super class description.
therefore one more ctor arg in this PubSubDeliveryException

public void testPublish_onFailureWithPayload() {
ListenableFuture<String> future = this.pubSubTemplate.publish("testTopic", this.pubsubMessage);
this.settableApiFuture.setException(new Exception("Publish failed"));
assertThatThrownBy(() -> future.get()).isInstanceOf(ExecutionException.class).hasMessageContaining("permanating")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to check in the test that we have already that new PubSubDeliveryException with expected this.pubsubMessage populated. I believe that was a main goal of this fix.

@@ -103,7 +105,8 @@ public void setMessageConverter(PubSubMessageConverter pubSubMessageConverter) {
@Override
public void onFailure(Throwable throwable) {
LOGGER.warn("Publishing to " + topic + " topic failed.", throwable);
settableFuture.setException(throwable);
PubSubDeliveryException pubSubDeliveryException = new PubSubDeliveryException(pubsubMessage, throwable.getMessage(), throwable);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't want to see the same throwable.getMessage() here again on top of stack trace.
I can get it in the stack trace anyway parsing a cause.
What I want to see is an explicit message indicating that exactly here in the PubSubTemplate we couldn't delivered a message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1
I think what you're logging should work here as well for the message:
"Publishing to " + topic + " topic failed."

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the code.

@meltsufin meltsufin added the pubsub GCP PubSub label Nov 11, 2019
@@ -103,7 +105,8 @@ public void setMessageConverter(PubSubMessageConverter pubSubMessageConverter) {
@Override
public void onFailure(Throwable throwable) {
LOGGER.warn("Publishing to " + topic + " topic failed.", throwable);
settableFuture.setException(throwable);
PubSubDeliveryException pubSubDeliveryException = new PubSubDeliveryException(pubsubMessage, throwable.getMessage(), throwable);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1
I think what you're logging should work here as well for the message:
"Publishing to " + topic + " topic failed."

@meltsufin meltsufin merged commit 07a316e into spring-attic:master Nov 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pubsub GCP PubSub
Development

Successfully merging this pull request may close these issues.

5 participants