Hello Patrick,
On Aug 1, 2011, at 20:39 , Patrick Ohly wrote:
> In a local slow sync between Evolution and Google Calendar I see the
> following problem:
> [...]
> * The server logs "Status: 403: originator exception" and
> "WARNING: Aborting Session with Reason Status 403 (REMOTE
> problem)".
>
> That says it all. The session ends here without finishing the slow sync.
>
> This is a bit too drastic.
> [...]
> Should it be turned into a local error along the were somewhere? I
> remember vaguely that we discussed something like that and came to the
> conclusion that a backend can return errors in the range <500 to the
> Synthesis engine. That's what SyncEvolution is doing here.
There's a place in localengineds.cpp (around line 3337) where all the error
codes are catched in a switch/case statement that should NOT abort the session,
but rather mark the item for "resend later", which means in the next session.
403 is not among these, because usually a auth problem is really fatal and
retry does not help.
For your case at hand, I'd recommend to translate that kind of 403 error to 417
(retry later) in the backend (or in the sentitemstatusscript), which means that
the backend has some hope that a retry in the next session might help.
Here's the excerpt from the switch statement which lists the error codes that
lead to retry-later behaviour, along with comments that describe the rationale
to catch these codes here and not let them abort the session:
case 424: // size mismatch (e.g. due to faild partial item resume attempt
-> retry will help)
case 417: // retry later (remote says that retry will probably work)
case 506: // processing error, retry later (remote says that retry will
probably work)
case 404: // not found (retry is not likely to help, but does not harm too
much, either)
case 408: // timeout (if that happens on a single item, retry probably
helps)
case 415: // bad type (retry is not likely to help, but does not harm too
much, either)
case 510: // datastore failure (too unspecific to know if retry might help,
but why not?)
case 500: // general failure (too unspecific to know if retry might help,
but why not?)
Note that the retry feature only works with DB backends that support resume (in
particular, the flag field in the ID mapping table), which was always the case
for SyncEvolution, IMHO.
Best Regards,
Lukas Zeller, plan44.ch
l...@plan44.ch - www.plan44.ch
_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
