Таким образом, пропускаемый токен, который я получаю от Graph API, - это число, основанное на моем понимании (я могу ошибаться), оно указывает, сколько писем необходимо пропустить.
В нашем приложении мы сохраняем этот токен пропуска в нашей базе данных / памяти, чтобы мы могли получить следующую страницу электронных писем. Поэтому, если, скажем, текущий токен пропуска пользователя равен 100, и перед тем, как мы отправим запрос на сервер с токеном пропуска 100, этот пользователь удалит 10 электронных писем, что произойдет, если все еще использовать этот токен пропуска 100?
Так как я не уверен, что делать с этим типом случая удаления электронных писем, наше приложение работает так: мы всегда ставим минус на токене пропуска (например, -10) и проверяем, можем ли мы найти какое-либо письмо или временное перекрытие между текущим ответом и предыдущим ответом, если нет перекрытия, мы делаем еще один минус с токеном пропуска. Это как походка назад. Мы прекращаем делать минус, пока не найдем совпадение.
Имеет ли это смысл? До сих пор я заметил, что некоторые ответы о пропущенных токенах дают nextLink значение null, хотя в папке входящих сообщений пользователя все еще находятся новые электронные письма. Кроме того, мы пропустили несколько электронных писем в течение примерно полугода (это означает, что электронная почта находится в папке входящих сообщений пользователя, но не доставляется нашим приложением).