Open Ettores88 opened 5 years ago
This stems from the fact that right now each completion results (except when in manual ack mode) in the writing of progress (see #128 for details).
Changing to single delivery would make for a very confusing API - this entire lib (and I'd venture, any sensible change feed consumption application) needs to be batch based for clarity. The bottom line is that it depends how order-sensistive the processing is (some folks can manage items as a batch in parallel, others need to do it sequentially due to assumptions based on write order etc). This is also a reason not to a system level 'ignore an item' facility - it'd have to work in all these consumption modes.
Having said all this... it would be great if the batch processor were to be passed an expando object with properties along with the batch which is held in the lease, and have the ability to supply an update to this state
info when completing a batch. If that was to be provided, one might also want to expose a way to manually edit via a tool, a la https://github.com/Azure/azure-documentdb-changefeedprocessor-dotnet/issues/123#issuecomment-461541465 - this would allow one to communicate a 'poison message to be skipped' identity to the processor externally too.
Problem
The watcher of our collections continue to produce the same output. We found that it was induced from the processing of the same documents over and over.
Cause
One of the documents generate an exception during it transformations and all the documents weren't marked as elaborated. This means that overriding the method ProcessChangesAsync could introduce loop or freeze when an exception is thrown and not properly managed.
Solution
We decided to catch the exception, log it and move on. At the moment this is not a problem for us but would be better to have another solution.
Question
Are there better options to process the documents? For example an override of a methods that received only one of the documents. In this way the base class know exactly which document is processed and which not.
Example: If I found a document that broke my code I want to leave it there untouched until I release a new version of the code able to manage it properly.