http://bugzilla.meego.com/show_bug.cgi?id=997
Summary: Scheduleworld: Duplicate items at client after a
network failure sync session and a later retry sync
Classification: MeeGo Projects
Product: SyncEvolution
Version: unspecified
Platform: Netbook
OS/Version: IA
Status: WAITING FOR UPSTREAM
Severity: enhancement
Priority: Low
Component: SyncML
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
CC: [email protected],
[email protected]
Estimated Hours: 0.0
This is from http://bugzilla.moblin.org/show_bug.cgi?id=3733
Description From Chen Congwu 2009-06-22 18:32:58 PST (-) [reply]
While I was testing SyncEvolution in network failure cases with scheduleworld,
I found this issue.
Backgroud:
The tests have 2 clients (A and B), initially A and B each create 3 items and
sync to server, then both sync with server again to get all 6 items.
Afterwards,
1) B create another item (7th), sync with server (call this session
ChangsFromB), but it failed due to network error.
2) B later retries the sync session and successfully finished. (RetryB)
3) A later sync with server in hope to get the 7th item. (ToA)
Buggy Status:
1) During RetryB, the server refuses the resume request issued by SyncEvolution
and insists a slow sync. B then sent all 7 items to server and get 6 418 status
and 1 201 status.
2) During ToA, the server sends 3 Replace Cmd and 4 Add Cmd to A, causing 3
duplicate items at A.
Impact:
1) After a network failure, the client and server need a slow sync to get in
sync again which is not perfect(In OMA-DS 1.2.1, this scenario is covered by
suspend and resume).
2) Even through this slow sync, the server must do something unexpected causing
duplicated items at client side.
To Reproduce:
Pull the source from syncevolution git (git://git.moblin.org/syncevolution
suspend_resume branch), Run with: CLIENT_TEST_SERVER=scheduleworld
CLIENT_TEST_EVOLUTION_PREFIX=file:///tmp/test ./client-test
Client::Sync::vcard30::Retry::testInterruptResumeClientAdd
------- Comment #1 From Chen Congwu 2009-06-25 21:34:01 PST (-) [reply] -------
Add new results from suspend tests. The previous tests were under network abort
conditions, which seems scheduleworld could not resume.
This time we tested suspend scenarios: SyncEvolution will suspend just after
receiving each message, the result is:
1. If suspended just after message#1 (sync init), next sync SyncEvolution will
ask for normal sync, it is OK.
2. If suspended after message#2 (after sending client changes), next sync will
be a resume, Scheduleworld resumes OK.
3. If suspended after later messages, Scheduleworld will still refuse client
resume request thus going to the same state as abort (client duplicated items).
The Suspend cases are:
Client::Sync::vcard30::Suspend::testUserSuspendClientAdd
------- Comment #2 From shuangeeer 2009-07-05 19:44:20 PST (-) [reply] -------
Add "Scheduleworld" to summary to make it more clear.
--
Configure bugmail: http://bugzilla.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.
_______________________________________________
Syncevolution-issues mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution-issues
