Re: Conflict Detection and Resolution

On Fri, Oct 18, 2024 at 4:30 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> 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.
>

Okay, makes sense. We should raise ERROR then.

thanks
Shveta