It is mentioned in cosmos docs that
With a push model, the change feed processor pushes work to a client that has business logic for processing this work. However, the complexity in checking for work and storing state for the last processed work is handled within the change feed processor.
But when I see the lifecycle of change feed processor library, it is as follows-:
1. Read the change feed.
2. If there are no changes, sleep for a predefined amount of time (customizable with WithPollInterval in the Builder) and go to #1.
3. If there are changes, send them to the delegate.
4. When the delegate finishes processing the changes successfully, update the lease store with the latest processed point in time and go to #1.
Looking at this lifecycle, it seems like we are polling changes from change feed instead of it pushing changes to us.
Is my understanding correct that the next set of changes will be pulled from change feed once my current delegate thread has finished or not? Is yes, how is this a push model and not a pull model?
Thanks in advance.
It is a push model to the user code (changes are pushed to the delegate, the user is not polling) but the underneath implementation is a poll and the flow is as described.
Remember the client library really just talks with the exposed service endpoints (REST APIs), there is no special push protocol (not gRPC for example), so clients can only do normal network requests (send request, get response).