Start new Conversation when publishing event

Architecture & Design
1

I have a scheduled handler that checks of certain contacts have changed in a specific period. When a change is detected the handler will send a ContactUpdated event for each changed contact.

The events are being handled, but they are all in the same conversation. This creates a big visual tree in ServiceInsight and Application Insight), which I’m not interested in.

A new conversation should be started when publishing the ContactUpdated event. I tried to do it as described here: Message Headers • NServiceBus • Particular Docs.

This doesn’t work for events. Is there a reason for that? Or is there another way to do this that I’m missing?

2

Hi @remyvd,

I had a quick look at the code and as far as I can tell, it should work using a CustomConversationIdStrategy.

Let me know if that works,
.m

3

I will try if that works for events.

I was asking because StartNewConversation() is not available on PublishOptions. Is there some best practice to not do that for events? :slight_smile:

4

We briefly discussed, and it makes sense to be able to start a new conversation when raising an event. I’ll raise an issue to flash out more details.

5

FYI, I raised the following issue: A new conversation cannot be started when publishing events · Issue #6722 · Particular/NServiceBus · GitHub

6

Are you referring to the NServiceBus scheduler?

That has limitations and it is advised to move away from it and obsolete in Core 8

With any of the other methods any message send via IMessageSession should result in a whole new conversation identifier as there is no previous message.

I think you’re stating that all scheduled invocations all share the same conversation identifier which to me also feels like unwanted behavior.

– Ramon

7

For me too, but if I recall I couldn’t even set the header with a new conversation id. NServiceBus is actively fighting me on this, so I was ‘is there some bad practice that I’m missing’.

Thanks for raising an issue!

No. I’m using timer-triggered Azure Functions (which I think you should add as an alternative in the documentation :-). They work great!)

In this context, being scheduled is not important. I just wanted to explain the use case.

A scheduled Azure Function sends periodically a CheckForUpdatedContacts command to an NServiceBus endpoint. This endpoint handles the command by checking for updates and publishing ContactUpdated event for each updated contact.

The CheckForUpdatedContacts command is the start of the conversation, but all ContactUpdated events join this conversation. In this context the ContactUpdated event should start its own conversation, because I’m not interested in the check trigger.

8

Thanks for clarifying. That does indeed make sense.

Done! Thanks for the suggestion!