| Summary | Send status 12 instead of http error 500 (eas v14.0) if requesting non-existing collectionId with syncKey != 0 |
| Queue | Synchronization |
| Queue Version | FRAMEWORK_5_2 |
| Type | Bug |
| State | Not Reproducible |
| Priority | 1. Low |
| Owners | mrubinsk (at) horde (dot) org |
| Requester | john.bieling (at) gmx (dot) de |
| Created | 11/10/2017 (2793 days ago) |
| Due | |
| Updated | 11/19/2017 (2784 days ago) |
| Assigned | 11/10/2017 (2793 days ago) |
| Resolved | 11/19/2017 (2784 days ago) |
| Github Issue Link | |
| Github Pull Request | |
| Milestone | |
| Patch | No |
official TbSync. I found this only by fuzzing around.
I created a special TbSync Version, which will reproduce the error every time:
https://github.com/jobisoft/TbSync/releases/download/v0.6.8.2/TbSync_horde_bug_14733.xpi
After you connected your account, right click in the folder list
section of the TbSync Account Manager and you will find the following
menuitem: "add folder to list which does not exist on server with
synckey != 0".
If you click that, a new folder "89" shows up. If you than hit the
"Sync this account" button, the sync fails with an HTTP error 500.
All this does is sending the request I included in the very first post
of this bug report. You can enable the debug log (under help) to see
what is send and received by TbSync.
John
State ⇒ Not Reproducible
Priority ⇒ 1. Low
The only way I can get TbSync to issue a SYNC for a collection that
does not exist is to delete one of the already synchronized folders
from Horde. The next time TbSync synchronizes, it seems to always
issues a FOLDERSYNC which, correctly, sends back the fact that the
folder was deleted. Therefore, the client should never (and TbSync
does not) issue the SYNC command with the non-existent collection.
If a SYNC was issued prior to the client receiving a FOLDERSYNC
response indicating it was removed, the Horde server should send back
a status 12, and from all the code paths I can trace, it seems to do
just that. If you have a step-by-step way of reproducing this or (even
better) you can provide a unit test that fails, I can investigate
further. Until then, I am closing this ticket as non-reproducible.
As written in one of my other tickets
(https://bugs.horde.org/ticket/14732) I am using TbSync for
Thunderbird to trigger this.
If the latest version of TbSync (see other ticket) is usable for you
(there was a UI bug on Apple Mac, which we talked about a few months
ago) I could provide a debug Version, which sends this request to
trigger the error, would that help?
Yours,
John
State ⇒ Feedback
From your examples I am assuming that you are using Horde_ActiveSync
as part of your own code. Can you provide more detail as to where the
500 is coming from?
I have added some code where it might have been causing this if your
backend doesn't behave exactly as Horde_ActiveSync_Driver_Base:: does.
Let me know if these changes fix things for you...
Assigned to Michael Rubinsky
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Send status 12 instead of http error 500 (eas v14.0) if requesting non-existing collectionId with syncKey != 0
Queue ⇒ Synchronization
Milestone ⇒
Patch ⇒ No
State ⇒ New
<Sync xmlns='AirSync'>
<Collections>
<Collection>
<SyncKey>5765765</SyncKey>
<CollectionId>89</CollectionId>
<DeletesAsMoves>1</DeletesAsMoves>
<WindowSize>100</WindowSize>
<Options>
<BodyPreference xmlns='AirSyncBase'>
<Type xmlns='AirSyncBase'>1</Type>
</BodyPreference>
</Options>
</Collection>
</Collections>
</Sync>
If CollectionId 89 does not exist, I should get back status 12. Horde
sends http error 500. (zPush and microsoft send status 12)
For comparison, if i send the same request with SyncKey 0, I get back
status 8, which is correct. (Microsoft sends 8, zPush sends 12)