В реестре значилось 763 актива... Заметка
DEV Community на русском

В реестре значилось 763 актива. На платформах — около 400.

Синхронизированный реестр вышел из строя незаметно, сообщив о 763 активах, хотя для рабочего аккаунта реально существовало около 400. Ручная проверка выявила это несоответствие путем изучения пользовательских интерфейсов и API платформы. Неточности в реестре были вызваны тремя различными режимами сбоя. "Призраки" представляли собой активы, удаленные с платформы, но все еще присутствующие в базе данных, что составило не менее 173 строк. "Пропуски" возникали, когда активы существовали на платформе, но никогда не были записаны в базу данных, что составило в общей сложности не менее 63 строк. "Ложные срабатывания" включали в себя значения по умолчанию платформы, которые ошибочно учитывались как пользовательские активы, что составило не менее 109 строк.Эти три режима частично компенсировали друг друга, делая общее количество вводящей в заблуждение метрикой. Конкретные примеры ошибок включали в себя неправильное отображение списка навыков платформы из 100 элементов из-за ограничения размера страницы, вместо 4 реальных навыков пользователя. Другой случай включал в себя сохранение текста-заполнителя со страницы настроек как пользовательских воспоминаний, в то время как реальные воспоминания были пропущены. Кроме того, 42 строки инструкций указывали на несуществующие локальные каталоги на машине. Главный урок заключается в том, что успешный отчет о синхронизации не гарантирует точности данных. Проблемы с пагинацией привели к пропуску активов, поскольку вызовы списков прекращались преждевременно, а правдоподобные цифры способствовали самоуспокоенности.Предлагаемое решение заключается не в лучшем сборщике, а в обязательной проверке после каждого синхронизации. Этот процесс включает в себя повторное чтение платформы и выполнение двунаправленного сравнения идентификаторов. Значения по умолчанию, предоставляемые платформой, должны быть явно идентифицированы и обработаны. Эта проактивная проверка, выполняемая по расписанию, имеет решающее значение для предотвращения деградации реестров. Автор разрабатывает управляющую плоскость под названием untactit, где эта проверка повторного чтения является основным уроком продукта.