RxDB 16.6.1 conflict handler deleted field mismatch

[troywweber7]

On our project we use deleted for the deleted field on our graphql backend, so that means I have set deletedField: 'deleted' on the replication options. When I write a custom conflict handler to try to merge changes, I was surprised to see a discrepancy.

The types for the conflictHandler.resolve method indicate that the shape of assumedMasterState and newDocumentState is identical to the shape of realMasterState. But at runtime, that does not appear to be true.

Since we are using the deletedField option and changing it, I could just account for this in the handler logic by type-asserting that the assumed state and new state actually have a slightly different shape than the real state. I would just make sure to return a resolution that matches the real state. But I figured I should submit an issue just in case anyone else has run into this.

Here is a snippet of the object I console logged.

{
    "newDocumentState": {
        "id": "9b61cadc-c29f-46d5-934b-ba60063f08ee",
        "updatedAt": 1739581928057,
        "firstName": "A",
        "lastName": "Second",
        "companyName": "Second",
        "deleted": true
    },
    "assumedMasterState": {
        "id": "9b61cadc-c29f-46d5-934b-ba60063f08ee",
        "updatedAt": 1739581839714,
        "firstName": "A",
        "lastName": "Second",
        "companyName": "Second",
        "deleted": false
    },
    "realMasterState": {
        "id": "9b61cadc-c29f-46d5-934b-ba60063f08ee",
        "updatedAt": 1739581935975,
        "firstName": "A",
        "lastName": "B",
        "companyName": "Second",
        "_deleted": false
    }
}

The logic would certainly be easier to write/understand if the same field was used at runtime for every entry in the RxConflictHandlerInput<Item>. So is this behaving as expected already? If not, should the values in RxConflictHandlerInput<Item> all have the user configured deleted or the internal RxDB _deleted?