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/Cli...
>>
>> 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/Cli...
>>
>> Update (same session):
>>
http://syncev.meego.com/2012-04-13-15-25_all/testing-amd64/23-memotoo/Cli...
>>
>> 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#m...
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.