Re: StartDataRead/EndDataWrite + invalid anchor
On Sa, 2011-09-10 at 12:32 +0200, Lukas Zeller wrote:
> Hello Patrick,
> On Sep 7, 2011, at 14:53 , Patrick Ohly wrote:
> > SyncEvolution's ActiveSync backend uses the sync anchor passed into
> > StartDataRead() for change tracking. The new anchor is created in
> > EndDataWrite(). The sync anchor is the ActiveSync "sync key", created
> > and updated by the ActiveSync server as changes are made to the data.
> > I now have the following situation: because of a misconfiguration of the
> > client, it attempts to start a sync with an invalid sync key. The
> > ActiveSync server rejects it in StartDataRead(), which returns a 10500
> > error code.
> > [...]
> > The error causes apiReadSyncSet() to bail out, without ever calling
> > EndDataWrite() in that session. Because the backend never gets the
> > chance to reset the sync anchor, the next sessions just do the same
> > thing again and again.
> Ok, I see the problem.
> StartDataRead() is unfortunately too late in the process of the SyncML
> protocol to convert the sync into a slow sync in the same session
> (latest point where this is possible is when handling the Alert from
> the server, which is before starting to read from the DB).
> But what we could do is allow StartDataRead to return 508 error code
> to have the engine reset sync anchors before bailing out, such that
> the next session would become a slow sync.
> Would that solve the problem?
It is sub-optimal because it will be visible to users. Currently
SyncEvolution doesn't automatically start a new sync. This will also
break the automated testing, which will bail out with that error instead
of doing a slow sync.
As one way of dealing with the problem adding such a special error code
is worthwhile. But perhaps there is a different way?
For example, could the datastore API extended with a "verify anchor"
call which is called soon enough to discard the anchor and fall back to
a slow sync?
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.