1956217 - [ews] Handle "ErrorInvalidSyncStateData" errors

Status: NEW

(Thunderbird :: Account Manager, defect)

Description

[Brendan Abolivier [:babolivier]]

If something has gone wrong on our end, the server might respond to a SyncFolderItems request with:

<?xml version="1.0" encoding="utf-8"?>
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
    <s:Header>
        <h:ServerVersionInfo MajorVersion="15" MinorVersion="20" MajorBuildNumber="8534" MinorBuildNumber="41"
            xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types"
            xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
        </s:Header>
        <s:Body>
            <m:SyncFolderItemsResponse
                xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages"
                xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns:xsd="http://www.w3.org/2001/XMLSchema"
                xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types">
                <m:ResponseMessages>
                    <m:SyncFolderItemsResponseMessage ResponseClass="Error">
                        <m:MessageText>Synchronization state data is corrupt or otherwise invalid.</m:MessageText>
                        <m:ResponseCode>ErrorInvalidSyncStateData</m:ResponseCode>
                        <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey>
                        <m:SyncState/>
                        <m:IncludesLastItemInRange>true</m:IncludesLastItemInRange>
                    </m:SyncFolderItemsResponseMessage>
                </m:ResponseMessages>
            </m:SyncFolderItemsResponse>
        </s:Body>
    </s:Envelope>

We don't handle this well, because it seems like we fail to account for the fact that an error response won't include a Changes element:

[ERROR ews_xpcom::client] an unexpected error occurred: Ews(Deserialize(Error { path: Path { segments: [Map { key: "Body" }, Map { key: "SyncFolderItemsResponse" }, Map { key: "ResponseMessages" }, Map { key: "SyncFolderItemsResponseMessage" }, Seq { index: 0 }] }, original: Custom("missing field `Changes`") }))

We should fix the type definition to better support this case.

In terms of how to actually handle this error, it's a bit tricky we can probably try sending the request again but with an empty sync token. It's a bit naff, because we'll be possibly replaying a lot of traffic, but I think we shouldn't fail any creation of existing message, deletion of already deleted messages, etc, in a way that would prevent us from processing the entire request (it would print errors or warnings to the terminal output, but shouldn't abort the overall operation).