Диагностика надстройки Outlook, которая сначала показывает startup error, но загружается после Retry и Start: отделяем manifest, Office.onReady, HTTPS-ресурсы и конкретный почтовый элемент.
Рассматривайте Retry как второй замер
Сообщение об ошибке при первом старте и успех после Retry не доказывают повреждённый manifest. Повторная попытка может отличаться прогретым кешем, готовностью Office.js, состоянием почтового элемента или доступностью внешнего HTTPS-ресурса. Запишите время открытия панели, появления первой ошибки, нажатия Retry и фактической готовности интерфейса. Если последовательность повторяется, временная шкала становится сильнее описания «иногда не работает». Не нажимайте Retry многократно до фиксации первой попытки.
Разделите manifest и веб-приложение
Outlook add-in состоит из manifest и веб-приложения с HTML и JavaScript. Manifest описывает интеграцию, требования и разрешения, а логика загружается по сети; Outlook add-ins требуют сетевого соединения. Проверьте, открываются ли исходная HTTPS-страница, Office.js и необходимые API без ошибок сертификата. Не включайте в отчёт токены и содержимое запросов. Если manifest не распознаётся, host-level runtime logging полезен; если страница загрузилась и ломается JavaScript, нужны developer tools, потому что runtime logging не собирает console.log.
Измерьте Office.onReady при первом старте
Microsoft отмечает, что Office.initialize и Office.onReady выполняются сразу при запуске runtime, до обычного подключения отладчика. Для Outlook on the web можно заранее открыть developer tools, установить точки остановки и повторно запустить панель в том же процессе браузера. Сравните первый запуск и Retry: дошёл ли код до onReady, какой host определён, закончились ли асинхронные зависимости. Не добавляйте искусственные задержки как постоянное исправление до измерения; задержка может скрыть гонку, не объясняя её.
Проверьте влияние элемента и окружения
Повторите тест на одном синтетическом письме чтения, затем на новом черновике, если надстройка поддерживает этот режим. Зафиксируйте Outlook on the web, браузер, тип элемента и поддерживаемый Mailbox requirement set. Если сбой возникает только на одном типе, не сводите его к сети. Если первая попытка ломается во всех элементах, а Retry всегда успешен, приоритет — загрузочная последовательность и зависимости. Сравнение в другом поддерживаемом браузере допустимо как контроль, но не заменяет сетевую трассу исходного запуска.
Соберите пакет без секретов и остановитесь
Для эскалации сохраните версию manifest без внутренних URL, ID надстройки в сокращённом виде, браузер, время, HAR после удаления cookies и Authorization, сообщения console и host-level runtime log. Runtime logging влияет на производительность, поэтому включайте его только на время воспроизведения и затем отключайте. Остановитесь, если тест требует реальных писем клиентов или публикации manifest на внешний домен. Диагностика достаточна, когда первый отсутствующий этап однозначно отличается от успешного Retry.
Материал подготовлен самостоятельно с автоматизацией и редакционно проверен 30 июля 2026 года по обезличенному публичному сигналу и официальной документации Office Add-ins; manifest, домены и содержимое писем автора не использовались.
Источники и проверка
- Microsoft Learn — runtime logging для Office Add-ins проверено 2026-07-30
- Microsoft Learn — отладка initialize и onReady проверено 2026-07-30
- Microsoft Learn — обзор Outlook add-ins проверено 2026-07-30
Информация актуальна на дату публикации. Правила сервисов, приложений и сетей могут меняться.