Google People API - упорядочение по времени обновления не работает должным образом

Question

Я успешно использую Google People API для получения моих контактов Google, но обнаружил, что API не выполняет сортировку правильно по времени последнего обновления (например, с использованием setSortOrder("LAST_MODIFIED_DESCENDING")). Более того, при просмотре вывода этого кода оказывается интересный паттерн:

  private static void getLastModified() throws GeneralSecurityException, IOException {
    PeopleService service = getService();
    ListConnectionsResponse response =
        service.people().connections().list("people/me")
        .setPageSize(30)
        .setPersonFields("names,metadata")
        .setSortOrder("LAST_MODIFIED_DESCENDING")
        .execute();
    for (Person person : response.getConnections()) {
      //System.out.println(person.getNames());
      for (Source s : person.getMetadata().getSources()) {
        if (s.getType().equals("CONTACT")) {
          System.out.println(s.getUpdateTime());
        }
      }
    }
  }

Результаты с порядком сортировки LAST_MODIFIED_DESCENDING:

2020-05-07T19:27:27.469Z    <-- ok (which means this contact is for sure modified by me on the given day)
2020-05-07T19:27:03.418Z    <-- ok
2020-05-07T19:26:20.219Z    <-- ok
2020-05-07T19:25:39.684Z    <-- ok
2020-05-07T19:25:13.823Z    <-- ok
2020-05-07T19:24:13.732Z    <-- ok
2020-05-07T13:04:47.637Z    <-- ok
2020-04-12T17:18:31.714156Z <-- NOT ok (contact is probably modified by me on that day, but why is it positioned incorrectly?)
2020-04-15T20:49:28.733412Z <-- NOT ok
2020-05-06T17:20:19.840Z    <-- ok
2020-05-06T17:18:22.134Z    <-- ok
2020-05-06T17:17:33.185Z    <-- ok
2020-05-06T16:41:00.368Z    <-- ok
2020-05-06T16:40:50.119Z    <-- ok
2020-05-06T15:02:49.218Z    <-- ok
2020-05-06T14:29:27.963Z    <-- ok
2020-05-06T14:28:40.890Z    <-- ok
2020-05-06T14:26:56.322Z    <-- ok
2020-05-06T14:26:04.658Z    <-- ok
2020-05-06T14:25:17.177Z    <-- ok
2020-05-06T14:24:12.801Z    <-- ok
2020-05-06T14:23:13.461Z    <-- ok
2020-05-06T14:22:04.888Z    <-- ok
2020-04-12T19:26:25.392253Z <-- NOT ok
2020-05-06T12:05:32.209Z    <-- ok
2020-05-06T11:57:11.286Z    <-- ok
2018-08-15T13:49:04.254001Z <-- NOT ok
2020-04-12T15:10:27.421184Z <-- NOT ok
2020-05-05T17:51:52.572Z    <-- ok
2020-05-05T17:50:43.904Z    <-- ok

После дальнейшего анализа, похоже, что все неуместные контакты имеют два типа объекта source в своей структуре metadata (CONTACT и PROFILE), из которых только CONTACT содержит временную метку updateTime, но API, очевидно, принимает во внимание другой один - отметка времени PROFILE, НЕ видимая через API. Другими словами, неуместные контакты из моего списка, вероятно, не потеряны, они скорее изменились по сравнению с их первоначальным владельцем, но API не показывает эту вторую временную метку.

Может ли кто-нибудь пролить свет на это и предложить как заставить API игнорировать источник метаданных PROFILE и сортировать только в соответствии с моими отметками времени модификации?

Answer 1

Спасибо @Raserhin за предложение опубликовать проблему в Google Issue Tracker - я сделал это, получил ответ и могу ответить на свой вопрос.

Что касается первой части вопрос:

Может ли кто-нибудь пролить свет на это ...?

На https://issuetracker.google.com/issues/156048409 Я получил подробное объяснение, подтверждающее мои предположения:

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

Вторая часть вопроса:

как сделать заставить API игнорировать источник метаданных PROFILE и сортировать только в соответствии с моими отметками времени модификации?

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