Support multiple ChangeFeed handlers for a single container

Is your feature request related to a problem? Please describe. In situations when you keep different types of documents in a single container you have a problem with change feed processor builder. Let me explain. Currently, you can build change feed processor like this:

var changeFeedProcessor = database
	.GetContainer("MyContainer")
	.GetChangeFeedProcessorBuilder("MyContainerChangeFeed", HandleChangesAsync)
        ...
        .Build();

where HandleChangesAsync has a type of ChangesHandler<T>. Here I have a problem. The type T here should be a type of a document which I want to feed. It works great if I have only one type of documents in the container. If I have more than one type of documents the only way how to deal with it is to use dynamic type and create handler which will manually parse the change object as JSON and cast it to the correct type. It saves me a lot of time and make code much cleaner if I can attach multiple handlers to the single container in the change feed processor builder.

Describe the solution you’d like It would be great to have API like this:

ChangesHandler<DocumentType1> HandleChangesAsync1 = (changes, token) => { ... };
ChangesHandler<DocumentType2> HandleChangesAsync2 = (changes, token) => { ... };

var changeFeedProcessor = database
	.GetContainer("MyContainer")
	.GetChangeFeedProcessorBuilder("MyContainerChangeFeed")
        .WithHandler(HandleChangesAsync1)
        .WithHandler(HandleChangesAsync2)
        ...
        .Build();

[Ceridan]

Yes, sounds fair. I think we may close this issue, you answered to all my questions. Thank you for the explanation and for your time.

[ealsur]

In order to support the Type pattern effectively and without a compute bottle beck, this would need to work as a backend filter, where you could just read the Change Feed for a particular subsets of documents (for example, where Type = Something). That is not possible currently and I’m not aware of any roadmap for it.

If it’s a feature that would need to be implemented in the client SDK, then it would simply do the same you are currently doing, basically take the List of documents and apply a filtering mechanism. I have not yet seen any other request for this in the repo, my guess is because it’s something that would be nice in the Type pattern scenario, but it’s not a blocker because it’s simple to implement and it doesn’t add any value to any other scenario.