---- Reported by jingke.zhang@intel.com 2010-04-13 00:54:38 +0000 ----

This issue is from BMO#2069 (http://bugzilla.moblin.org/show_bug.cgi?id=2069)

   Description  From  pohly   2009-05-08 04:43:03 PST   (-) [reply]

It would be nice if we had good explanations for the status codes generated
during a sync, both for individual sync sources and the overall sync result.
Right now the SyncEvolution command line simply prints the status code as part
of the sync reports.

Let's gather status codes which occurred in reality in this issue together with
an explanation of the different failures, perhaps we can come up with some
helpful texts for users.

------- Comment #1 From jku 2009-05-23 05:47:29 PST (-) [reply] -------

A specific group which I haven't worked on yet is SyncML return codes. It seems
these are codes 10000-20000 (subtract 10000 to get the SyncML error).

I just saw a 10412 (for all sources, next sync worked fine).


Log says:
  RECEIVED STATUS 200 for for command 'Replace' (outgoing MsgID=5, CmdID=5)
   - SourceRef (localID) = 'pas-id-4A0D398300000044'
  Found matching command 'Replace' for Status
  chunked object received status 200 instead of 213 --> aborting session
  [2009-05-23 13:09:42.291] 'SessionAbort' - Aborting Session, Status=412, 


Spec says 412 is: 
  "Incomplete command. The requested command failed on the
  recipient because it was incomplete or incorrectly formed. The
  recipient SHOULD specify the portion of the command that was
  incomplete or incorrect in the Item element type in the Status."

------- Comment #2 From pohly 2009-06-09 07:39:07 PST (-) [reply] -------

Error code 20043 = LOCERR_TRANSPFAIL is returned if the server sends back a
non-SyncML reply (https://bugs.meego.com/show_bug.cgi?id=3041).

------- Comment #3 From jku 2009-09-17 05:28:34 PST (-) [reply] -------

Managed to see a 418, which is "Already exists" according to synthesis source.

I wonder if this is supposed to come to me or if synthesis should handle it?
It's not in syerror.h anyway.

------- Comment #4 From pohly 2009-09-17 06:15:17 PST (-) [reply] -------

(In reply to comment #3)
> Managed to see a 418, which is "Already exists" according to synthesis source.

Can you reproduce it?

> I wonder if this is supposed to come to me or if synthesis should handle it?
> It's not in syerror.h anyway.

Could be that the engine passes through SyncML status codes that it receives
from the server.

------- Comment #5 From jku 2009-12-10 04:30:54 PST (-) [reply] -------

Saw a sync fail consistently with 500 (DB_Fatal). Log said: 

[ERROR] calendar: retrieving item: 20091210T110404Z-19227-1000-1-0@vili-rid:
Object not found


Restarting EDS fixed things.

------- Comment #6 From pohly 2009-12-16 08:22:52 PST (-) [reply] -------

I have added printing of a textual status explanation to the command line. The
output includes the distinction between errors detected locally and remotely
("local/remote") and the actual status code (because that is sometimes more
helpful than the description.

Here's an example, based on the "unexpected slow sync" error scenario where one
source runs into that problem and then the other and the whole session get
aborted automatically:


[INFO] addressbook: starting normal sync, two-way
[INFO] calendar: inactive
[ERROR] calendar: unexpected slow sync (local, status 22000)
[INFO] calendar: starting slow sync, two-way
[INFO] addressbook: preparing 1/68
[...]
[INFO] addressbook: preparing 68/68
[ERROR] Aborting because of unexpected slow sync for source(s): calendar
[INFO] Doing a slow synchronization may lead to duplicated items or
lost data when the server merges items incorrectly. Choosing
a different synchronization mode may be the better alternative.
Restart synchronization of affected source(s) with one of the
following sync modes to recover from this problem:
    slow, refresh-from-server, refresh-from-client

Analyzing the current state:
    syncevolution --status syncevolution_client calendar

Running with one of the three modes:
    syncevolution --sync [slow|refresh-from-server|refresh-from-client]
syncevolution_client calendar

[INFO] addressbook: normal sync done unsuccessfully
[ERROR] addressbook: aborted on behalf of user (local, status 20017)

Synchronization failed, see
/home/pohly/.cache/syncevolution/syncevolution__client-2009-12-16-17-21/syncevolution-log.html
for details.

Changes applied during synchronization:
+---------------|-------ON CLIENT-------|-------ON SERVER-------|-CON-+
|               |   rejected / total    |   rejected / total    | FLI |
|        Source |  NEW  |  MOD  |  DEL  |  NEW  |  MOD  |  DEL  | CTS |
+---------------+-------+-------+-------+-------+-------+-------+-----+
|   addressbook |  0/0  |  0/0  |  0/0  |  0/0  |  0/0  |  0/0  |  0  |
|   two-way, 0 KB sent by client, 0 KB received                       |
|   item(s) in database backup: 68 before sync, 68 after it           |
|   aborted on behalf of user (local, status 20017)                   |
+---------------+-------+-------+-------+-------+-------+-------+-----+
|      calendar |  0/0  |  0/0  |  0/0  |  0/0  |  0/0  |  0/0  |  0  |
|      slow, 0 KB sent by client, 0 KB received                       |
|      item(s) in database backup: 13 before sync, 13 after it        |
|      unexpected slow sync (local, status 22000)                     |
+---------------+-------+-------+-------+-------+-------+-------+-----+
|          start Wed Dec 16 17:21:04 2009, duration 0:04min           |
|           aborted on behalf of user (local, status 20017)           |
+---------------+-------+-------+-------+-------+-------+-------+-----+

------- Comment #7 From jku 2010-02-09 00:57:41 PST (-) [reply] -------

Documentating this weird error as well:

When I try to sync with a bluetooth device and fail in a transport related way
I get 10500 (LOCAL_STATUS_CODE + DB_Fatal). The real problem can be e.g. the
phone being out of range or unexpectedly disconnecting (like Nokia N85 seems to
do when it encounters a difficult situation):

This is what syncevolution command line prints when phone is out of range:
 [ERROR] ObexTransport: Transport Exception in sdp_source_cb
 [ERROR] TransportException while sending SAN package
 [ERROR] Server Alerted Sync init failed

------- Comment #8 From jku 2010-02-09 00:58:22 PST (-) [reply] -------

(In reply to comment #7)
> Documentating this weird error as well:
> 
> When I try to sync with a bluetooth device and fail in a transport related way
> I get 10500 (LOCAL_STATUS_CODE + DB_Fatal). 

This is via the DBus api of course.

------- Comment #9 From pohly 2010-02-09 08:14:47 PST (-) [reply] -------

(In reply to comment #7)
> Documentating this weird error as well:
> 
> When I try to sync with a bluetooth device and fail in a transport related way
> I get 10500 (LOCAL_STATUS_CODE + DB_Fatal).

*All* attempts to do Bluetooth with syncevo-dbus-server will fail, see https://bugs.meego.com/show_bug.cgi?id=9436.

> The real problem can be e.g. the
> phone being out of range or unexpectedly disconnecting (like Nokia N85 seems to
> do when it encounters a difficult situation):
> 
> This is what syncevolution command line prints when phone is out of range:
>  [ERROR] ObexTransport: Transport Exception in sdp_source_cb
>  [ERROR] TransportException while sending SAN package
>  [ERROR] Server Alerted Sync init failed

What kind of status do you expect in this case? Does the command line record it
as expected?

------- Comment #10 From pohly 2010-03-15 03:32:45 PST (-) [reply] -------

(In reply to comment #9)
> > This is what syncevolution command line prints when phone is out of range:
> >  [ERROR] ObexTransport: Transport Exception in sdp_source_cb
> >  [ERROR] TransportException while sending SAN package
> >  [ERROR] Server Alerted Sync init failed
> 
> What kind of status do you expect in this case? Does the command line record it
> as expected?

The SAN code was changed so that a transport failure now gets reported as one,
instead of catching the transport exception and rethrowing a generic error (the
root cause for the 500 status).

------- Comment #11 From pohly 2010-03-15 03:34:46 PST (-) [reply] -------

We should move the "status to localized error description" code from the
sync-ui into a library. The syncevo-dbus-server needs this for error
notifications. Other GUIs might also benefit from it.

We can either put it into libsyncevolution or create a new utility lib. Despite
the overhead with setting that up I prefer the later. It should have a stable
ABI/API, in contrast to libsyncevolution.



--- Bug imported by patrick.ohly@gmx.de 2012-07-29 20:36 UTC  ---

This bug was previously known as _bug_ 668 at https://bugs.meego.com/show_bug.cgi?id=668