Обработка ошибок 404 при внесении изменений в Google Диск

Question

Я работаю над приложением, которое отслеживает учетную запись пользователя для изменений с помощью watch endpoint. При каждом входящем изменении наше приложение затем отправляется на получение изменения с помощью get endpoint, чтобы его можно было правильно обработать.

Однако есть определенные случаи, когда запрос на получение изменения возвращает ошибку 404. Мы смогли достоверно воспроизвести эту проблему с файлами изображений, в частности png и jpeg, перетащив файл с компьютера в пользовательский интерфейс диска, чтобы загрузить его. Как ни странно, эта проблема не возникает для большинства типов файлов (насколько мы видели).

Мы попытались использовать повтор с экспоненциальным отступлением, но, похоже, изменений просто нет. Это пример ответа, который я получил через инструменты в документации API для получения определенного изменения, которое имело эту проблему.

{ 
"error": { 
    "errors": [ 
    { 
    "domain": "global", 
    "reason": "notFound", 
    "message": "Change not found: 18061", 
    "locationType": "other", 
    "location": "change" 
    } 
    ], 
    "code": 404, 
    "message": "Change not found: 18061" 
} 
} 

Один потенциальный обходной путь мы смотрим на использование было бы выполнить запрос на все файлы пользователя с помощью параметра ModifiedDate искать файлы за последние 10 секунд или около того, но обработка изменения непосредственно является гораздо более удобный способ работы.

Update

Мы играли с этим немного больше и нашел некоторые другие случаи, когда изменения надежно возвращать ошибки 404:

• Когда файл любого типа перемещается в мусор (если открыть его, когда он находится в помойке, действительное изменение приходит через)
• когда файл любого типа удаляется из корзины

Update 2

После некоторого серьезного копания, оказывается, что если вычесть 1 из «changeId» число поступающих из уведомления часов, мы можем получить действительное уведомление от API, который имеет точное изменение мы ожидаем. Хммм ...

Update 3

Когда файл, который находится в мусор удаляется, «changeId» число, которое мы получаем должно быть уменьшено на 2, чтобы получить надлежащее событие.

Answer 1

Что происходит, так это то, что изменение, о котором вы были уведомлены, было объединено с другим аналогичным изменением, которое произошло сразу после него и было удалено. В общем случае нецелесообразно напрямую запрашивать идентификатор изменения в уведомлении, поскольку сетевые условия и другие проблемы могут помешать уведомлению вашего приложения о каждом отдельном изменении.

Вместо этого, когда вы получаете и нажимаете уведомление, вы должны использовать его в качестве сигнала о необходимости синхронизации всех изменений, произошедших с момента последнего синхронизирования. В этом случае используется конечная точка Changes.list() и задайте startChangeId идентификатору последнего изменения, которое вы ранее синхронизировали.