Синхронизация новых событий календаря всегда имеет поле @removed

Я синхронизирую события календаря с помощью пакета @microsoft/microsoft-graph-client npm с базовым URL /me/calendarview/delta. Несколько дней назад он работал нормально. По какой-то причине всякий раз, когда я создаю новое календарное событие на outlook.office.com и мое приложение синхронизируется, для вновь созданного календарного события устанавливается поле @removed: {reason: "deleted"}.

Однако, когда я просматриваю то же событие календаря с помощью Microsoft Graph Explorer, для этого же события НЕ установлено поле @removed. Есть ли причина, по которой вновь созданное событие календаря будет выглядеть так, как будто оно удаляется во время синхронизации? Я использую @ microsoft / microsoft-graph-client v1.3.0

Шаги по воссозданию:

  1. Создайте событие, используя клиент графа узлов, отправив POST на /me/calendar/events
  2. Получите дельту календарных событий, используя /me/calendarview/delta с соответствующей deltaLink и токеном доступа.
  3. Я получаю 1 календарное событие с 3 полями: @odata.type, id и @removed. Поле id соответствует идентификатору события, созданного на шаге 1.

Если вам нужна дополнительная информация, дайте мне знать. Это влияет на некоторых наших пользователей.

Обновление. Я попытался решить эту проблему, вызывая /me/events/<id> для каждой @removed записи календаря, получаемой при дельта-синхронизации, чтобы проверить, действительно ли событие было удалено. Однако, когда я вызываю этот API через microsoft-graph-client, он возвращает null. Если я сделаю тот же вызов GET через MSFT Graph Explorer, событие будет возвращено.


microsoft-graph-api microsoft-graph-calendar microsoft-graph-sdks
person user1157236    schedule 12.02.2019    source источник
comment
Не могли бы вы добавить пример того, что вы получаете от Graph Explorer?   -  person Marc LaFleur    schedule 29.03.2019
comment
Я сталкиваюсь с той же проблемой, используя реализацию retrofit2 MS Graph. Вы нашли какое-либо решение или обходной путь?   -  person mattlaabs    schedule 13.12.2019
comment
Для меня это происходит только тогда, когда новое событие выходит за пределы временного интервала начала и конца дельта-запроса.   -  person mattlaabs    schedule 13.12.2019
comment
Привет, у меня такая же ошибка, хотя событие действительно не удалено в календаре. Итак, удача?   -  person uma mahesh    schedule 20.05.2020
comment
Я так и не нашел решения, я пошел дальше после того, как реализовал обходной путь в обновлении. Обратите внимание: я никогда не указывал временные рамки начала и конца в запросе дельты, например @mattlaabs, просто использовал ссылку дельты   -  person user1157236    schedule 21.05.2020
comment
@ user1156236 параметры start + end являются обязательными для исходного запроса и всегда будут применяться к будущим запросам с использованием дельта-ссылки.   -  person mattlaabs    schedule 22.05.2020

Ответы (1)


arrow_upward
2
arrow_downward

Я оставил здесь ответ на другой вопрос: https://stackoverflow.com/a/65348721/6806302

Короче говоря, вчера я ушел на догадку, вдохновленную Комментарий @ mattlaabs к вопросу выше, что виноват диапазон startDateTime..endDateTime дельты событий.

И на практике проблема именно в этом. Ответ состоит из двух частей:

  1. Изменения событий вне окна всегда отображаются в дельта-потоке как @removed.
  2. Параметры дельты событий фиксируются в закрытии, что означает, что последующие запросы (с $deltatoken) игнорируют параметр запроса startDateTime..endDateTime.

Понимая оба вышеперечисленного, кажется, что ответ таков:

  1. Создавайте достаточно широкие начальные startDateTime..endDateTime окна, чтобы удовлетворить потребности вашего приложения
  2. Запускать новые потоки дельты событий (не предоставляя $deltatoken) через определенный интервал вместо повторного использования одного и того же на неопределенный срок.
person Cory Boyd    schedule 17.12.2020