RE: Conflict Detection and Resolution

On Wednesday, October 9, 2024 2:34 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Wed, Oct 9, 2024 at 8:58 AM shveta malik <shveta(dot)malik(at)gmail(dot)com>
> wrote:
> >
> > On Tue, Oct 8, 2024 at 3:12 PM Nisha Moond
> <nisha(dot)moond412(at)gmail(dot)com> wrote:
> > >
> >
>
> Please find few comments on v14-patch004:
>
> patch004:
> 1)
> GetConflictResolver currently errors out when the resolver is last_update_wins
> and track_commit_timestamp is disabled. It means every conflict resolution
> with this resolver will keep on erroring out. I am not sure if we should emit
> ERROR here. We do emit ERROR when someone tries to configure
> last_update_wins but track_commit_timestamp is disabled. I think that should
> suffice. The one in GetConflictResolver can be converted to WARNING max.
>
> What could be the side-effect if we do not emit error here? In such a case, the
> local timestamp will be 0 and remote change will always win.
> Is that right? If so, then if needed, we can emit a warning saying something like:
> 'track_commit_timestamp is disabled and thus remote change is applied
> always.'
>
> Thoughts?

I think simply reporting a warning and applying remote changes without further
action could lead to data inconsistencies between nodes. Considering the
potential challenges and time required to recover from these inconsistencies, I
prefer to keep reporting errors, in which case users have an opportunity to
resolve the issue by enabling track_commit_timestamp.

Best Regards,
Hou zj