[os-libsynthesis] Google Calendar + per-item permission errors
Hello! In a local slow sync between Evolution and Google Calendar I see the following problem: * Both sides have a meeting event in almost the same state. * The Synthesis engine decides that the event in Google Calendar needs to be updated. * The PUT command fails with "403 You don't have access to change that event." * This error code is returned as SyncML status for Replace from SyncML client to server. * 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. I'd prefer to continue the session and merely report that this one item couldn't be updated. Never mind that this is my own calendar and that Google should allow me to modify all of the events in it... I wonder whether the 403 HTTP error really should be passed through like that. It gets returned by the Synthesis backend: * [2011-08-01 18:20:56.785] PUT: bad HTTP status: , must not retry * [2011-08-01 18:20:56.786] Running destroy hooks. * [2011-08-01 18:20:56.786] Request ends. * [2011-08-01 18:20:56.786] exception thrown at /home/pohly/syncevolution/syncevolution/src/backends/webdav/NeonCXX.cpp:685 * [2011-08-01 18:20:56.786] error code from SyncEvolution access denied (remote, status 403): PUT: bad HTTP status: * [2011-08-01 18:20:56.786] aID=(04008200E00074C5B7101A82E008B0884FC7A4E8CB01159F761E3FE944408F8932B4E44FFBFD.ics/20110428T15Z,) res=403 * [2011-08-01 18:20:56.786] cannot update record in database (sta=403) * [2011-08-01 18:20:56.786] Database Error --> SyncML status 403 * [2011-08-01 18:20:56.786] - Operation replace failed with SyncML status=403 –[2011-08-01 18:20:56.786] End of 'Process_Item' [->top] [->enclosing] * [2011-08-01 18:20:56.786] processSyncOpItem: Error while processing item, status=403 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. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] Google Calendar + per-item permission errors
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
Re: [os-libsynthesis] Google Calendar + per-item permission errors
On Di, 2011-08-02 at 15:39 +0200, Lukas Zeller wrote: > 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. I followed that approach. It means that the problematic item will be sent again and again, but that's better than the alternatives (abort session or only logging the issue). I still need to understand better how I arrived at this situation, though. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
