UserProperties Comes null on Conflict resolution

Hi, today i’m passing trouble to solve some conflicts that happen in my application, until last month I was able to solve my conflict rules accessing the UserProperties object of the ParentId of two or more branchs needing to merge. But after a while that UserProperties always coming null and i cannot do some MAth operations that are stored in the dictionary object and solve business rules =/

I’m using CBLite 1.4.1, Sync gateway 1.5.1, .NET Platform

The image from link bellow I highlighted that i need the value but always comes null.
I Thinked i could read the Revision History values because sometimes works, but other no.
I can see cases where i Cant see my objects above 2 revisions past
12-jdsaijdsiajdasi -> UserProperties has value (current always have value)
11-dsandaewqeiw -> UserProperties has value
10-iweqwjeiwqei -> UserProperties null

I think that pruning could be my problem, but i really think strange in cases where there are so few conflicts or revision increments, because i readed that default Couchbase Lite is 20 rev deep tree so i’m having problem with 3, or 8 updates in the worst scenario.

Am I Leaving something behind?

CBL keeps the metadata of the last 20 revisions, but it’s only guaranteed to keep the body of the current one. In practice it does keep old revision bodies until you compact the database. Are you calling Database.Compact?

I Checked and don’t call Database.Compact.

I can see my revision metadata (revision Id, and some strings informations) , but the data of the revision is null except for the most recent copy of each branch.

Today for me to solve the conflict i need to check the two documents of conflicts and do a Math Operation Based on Parent of both , i know the revision if there are is a way to get the parent body with Revision id.

Well I’m gonna check more deeply the Leaf Revision Collection to see if i can extract my data in there, or to increase my RevDeepTree

That is odd that things suddenly stopped working. With a maxRevDepth of 20, you shouldn’t run the risk of pruning and you indicated that you don’t do compaction. So are you suggesting that the problem happens over time or can you determine what changed in the interim that may have resulted in the issue - was the maxRevDepth inadvertently changed to 2 or instance?

BTW, this is a blog on related topic (although you have already checked out pruning and compaction).

Are you using ForestDB? That will periodically auto-compact without explicit Compact calls.