Skip to content
This repository has been archived by the owner on Oct 12, 2023. It is now read-only.

[WIP] Add the option to modify properties when abandoning a message #646

Closed
wants to merge 6 commits into from

Conversation

0xced
Copy link
Contributor

@0xced 0xced commented Feb 13, 2019

This is useful to store exception details when abandoning a message and still keeping the convenience of registering a message or session handler with AutoComplete = true

This is useful to store exception details when abandoning a message and still keeping the convenience of registering a message or session handler with AutoComplete = true
@0xced 0xced requested a review from a team as a code owner February 13, 2019 09:54
Copy link
Collaborator

@SeanFeldman SeanFeldman left a comment

Choose a reason for hiding this comment

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

Good feature.
Please add a test to verify behaviour. Thanks.

}
catch (Exception exception)
{
MessagingEventSource.Log.MessageReceiverPumpUserCallbackException(this.clientId, message, exception);
Copy link
Collaborator

Choose a reason for hiding this comment

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

What this exception will look like? Will it contain enough info to understand that it's the user provided callback that has 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.

At this point, the user callback threw an exception so the pump is abandoning the message. We let the user execute a second callback to return a dictionary of properties to modify on the message being abandoned, most likely to store details about the exception on the message itself. If that second callback fails, we don't want to fail abandoning the message so we just ignore the properties to modify and pass null (the default value). I'm not sure what else could be done, did you have something in mind?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Logging that exception? My thought is the following:
Processing callback fails, message is going to be abandoned. Properties modifier callback is failing, the same log message will be made with a different exception, using MessagingEventSource.Log.MessageReceiverPumpUserCallbackException() variant. Perhaps it should be a more specific Log method to distinguish between callbacks? That would suffice imo.

@SeanFeldman SeanFeldman changed the title Add the option to modify properties when abandoning a message [WIP] Add the option to modify properties when abandoning a message Feb 14, 2019
@SeanFeldman
Copy link
Collaborator

Marked PR as [WIP] until it's not and ready to be merged.

@SeanFeldman
Copy link
Collaborator

@0xced could you please

  • Remove WIP if no more work will be done
  • Rebase to unblock merging

@SeanFeldman
Copy link
Collaborator

@nemakam would you like to review as well?

@SeanFeldman SeanFeldman added this to the 3.4.0 milestone Mar 11, 2019
@nemakam
Copy link
Contributor

nemakam commented Mar 11, 2019

@0xced @SeanFeldman - I'm somehow not convinced we need this feature. We are complicating a lot of things and adding new params just so that you could you AutoComplete=true. RegisterMessageHandler() is for extreme novice users who do not know the intricacies of SB and just want a working solution. We do have a way for advanced users to do whatever they wish to. I feel this feature will confuse more people than help (since abandoning with some property seems to be a very minority case). Sorry to be the party popper here. The code itself looks good, but I don't think we would need this feature.

@nemakam
Copy link
Contributor

nemakam commented Mar 11, 2019

I'm thinking more in terms of number of novice users who are going to struggle understanding what to pass for that property as compared to number of users who will benefit with this feature.
What do you think?

Copy link
Contributor

@nemakam nemakam left a comment

Choose a reason for hiding this comment

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

Blocking on this PR to evaluate the feature requirements.

@SeanFeldman
Copy link
Collaborator

I'm thinking more in terms of number of novice users who are going to struggle understanding what to pass for that property as compared to number of users who will benefit with this feature.

I'll note that @0xced is not a novice user. As well as message handler while initially planned as an entry level API is actually more sophisticated for "newbies" that Send/Receive pattern. When it comes to implementing a message pump, suspect at that point we no longer talking about novice users at all. It's either using message handler to avoid the headaches or creating one from a scratch if the built-in doesn't cut it.

What do you think?

The API is extended, meaning users will have both options - w/ or w/o properties to update on abandon operation. Yes it adds to the public API surface, but it also adds flexibility to the MessageHandler API, which will auto-abandon but not allow to update properties. Thinking about it even more, if you want to update properties today, you have to entirely opt-out of MessageHandler, which is a shame if you don't want to build your own message pump.

So when it comes to 👍/👎 I tend to think that this API extension is a nice addition.

@nemakam
Copy link
Contributor

nemakam commented Mar 12, 2019

Thinking about it even more, if you want to update properties today, you have to entirely opt-out of MessageHandler, which is a shame if you don't want to build your own message pump.

You should just be able to do that within the handler right. The feature that you will miss out on is AutoComplete. If you can do a try-catch within your code, and abandon the way you want to abandon, that should do it for you.
Given that this is just a sugar syntax we are talking about, I am inclined towards not making it complicated. Its not a mainline scenario that we are targetting in this case.

@SeanFeldman
Copy link
Collaborator

You have a valid point @nemakam.

@0xced do you agree?

@SeanFeldman SeanFeldman removed this from the 3.4.0 milestone Mar 15, 2019
@0xced
Copy link
Contributor Author

0xced commented Mar 21, 2019

That’s currently what I’m doing (try+complete/catch+abandon in the handler) and precisely what led me to open this pull request. But I agree that it complicates the API.

I have thought about a simpler solution that I just proposed in #671.

@SeanFeldman
Copy link
Collaborator

Closing in favour of #671

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants