On Wed, 2012-04-18 at 18:07 +0200, Thomas Pequet wrote: > > ------------------------------------- > > Unexpected update sent back to client: > > > > http://syncev.meego.com/2012-04-13-15-25_all/testing-amd64/23-memotoo/Client_Sync_eds_event_testCopy.log.html > > > > Could this be related to a change for handling the case where the server > > resolves a conflict (see earlier discussion around testMerge)? Or > > perhaps it is simply a timing issue? If it is timing, then the > > client-side test driver cannot do anything about it, because it happens > > inside a single sync session. > > > > In the testCopy case, client A is sending an item that the server > > doesn't have (Add). Why is the server sending back an update for it? > > > > Send: > > http://syncev.meego.com/2012-04-13-15-25_all/testing-amd64/23-memotoo/Client_Sync_eds_event_testCopy.send.client.A/syncevolution-log_trm002_003_outgoing.xml > > > > Update (same session): > > http://syncev.meego.com/2012-04-13-15-25_all/testing-amd64/23-memotoo/Client_Sync_eds_event_testCopy.send.client.A/syncevolution-log_trm003_006_incoming.xml > > > > testCopy only failed for events, worked for contacts, tasks and notes. > > > > Same failure in testAddUpdate for events (Add command) *and* tasks (but > > at a different part of the test, after the Replace command). > > > > I've spot-checked some of other failures, they all seem to be about this > > unexpected update. > > ------------------------------------- > This problem is strange because I can not reproduce it ...
I'm not seeing it either when running the eds_event::testCopy test manually now. It succeeds 5 out of 5 times, with and without valgrind. It still failed in the full test over the weekend: http://syncev.meego.com/2012-04-20-15-16_all/testing-amd64/nightly.html#memotoo But even that isn't deterministic: some tests passed which failed earlier (green), some failed only now (red). > Does this problem is also with actual SyncML server > (http://www.memotoo.com/syncml";) ? Not as far as I remember. The logs don't go back that far. I'll switch to the regular server for another full run. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
