Ryan Wynn

Monstache is executing the `replSetGetStatus` command to retrieve the timestamp after the direct reads are complete. I don't believe DocumentDB supports this command. It's possible to solve using `serverStatus` command...

Hi @chanpl is there anything in particular that doesn't work well with OpenSearch? My understanding is that the subset of APIs used by monstache should be compatible and still relevant...

Hi @ScubaDrew, what @benlavalley said is correct about reading from a secondary using the `readPreference`. There is currently no way to save the resume token anywhere other than in MongoDB...

Hi @benlavalley glad to hear things are going well with your migration. I'm not sure if the replication lag would affect resuming monstache since it's saving and restoring the `clusterTime`...

It also seems that change event notification (send to monstache) only happens after the change has persisted to a majority. https://docs.mongodb.com/manual/changeStreams/#event-notification

Hi @yoitsro yeah this is tricky. I think it might be possible to work around this by adding the `txnNumber` from the change event to the version number. What do...

Monstache does rely on the version number to ensure updates to Elasticsearch are done correctly when multiple events happen nearly simultaneously on a document.

Based on this answer I'm not sure `txnNumber` would help us here: https://stackoverflow.com/questions/65038952/get-all-documents-involved-in-a-transaction-when-using-change-streams-in-mongodb Because it would be the same number for Create document / Update document since they are part...

hey @yoitsro the only other thought I have is to allow configuring Monstache to add 1 to the version number (derived from the clusterTime of the change event) of all...

I suppose to revise I would go with insert version = timestamp update version = timestamp + 1 delete version = timestamp + 2 that should handle most txn scenarios...