Какой длины могут быть сообщения при отправке в веб-перехватчик соединителя Microsoft Teams?
Я отправляю результаты / журналы системы CI/CD в Microsoft Teams. При обработке некоторых неудачных сборок с более длинными результатами я наткнулся на следующую ошибку, возвращаемую URL-адресом веб-перехватчикаhttps://outlook.office.com/webhook/bb6bfee7-1820-49fd-b9f9-f28f7cc679ff@<uuid1>/IncomingWebhook/<id>/<uuid2>
:
Webhook message delivery failed with error: Microsoft Teams endpoint returned HTTP error 413 with ContextId tcid=3626521845697697778,server=DB3PEPF0000009A,cv=BmkbJ1NdTkv1EDoqr7n/rg.0..
Как я заметил, это вызвано слишком длинной полезной нагрузкой, отправленной на URL-адрес веб-перехватчика команд.
Исходное сложное сообщение (разделы, заголовки, субтитры, форматированные ссылки, <pre>
форматированный текст и т. д.) не работал, когда полезная нагрузка JSON превышала 18000 символов.
Немного протестировав полезную нагрузку, я заметил, что чем больше форматирования я удаляю из необработанной полезной нагрузки JSON, тем длиннее может быть сообщение Teams. Самое длинное сообщение, которое я мог опубликовать, было (согласно cu cURL):Content-Length: 20711
. Полезные данные JSON для этого сообщения:
{"themeColor":"ED4B35","text":"a....a"}
пробелы в формате JSON, похоже, не учитываются (т.е. добавление пробелов не приведет к уменьшению максимальной длины сообщения, которое я могу отправить на веб-перехватчик Teams).
Для справки, исходное сообщение выглядело примерно так:
{
"themeColor": "ED4B35",
"summary": "iris-shared-libs - shared-library-updates - failure",
"sections": [
{
"activityTitle": "Job: [iris-shared-libs](https://my.concourse.net/teams/hsm/pipelines/iris-shared-libs) - [shared-library-updates #89](https://my.concourse.sccloudinfra.net/teams/hsm/pipelines/iris-shared-libs/jobs/shared-library-updates/builds/89) (FAILURE)",
"activityImage": "https://via.placeholder.com/200.png/ED4B35/FFFFFF?text=F",
"facts": [
{
"name": "Failed step",
"value": "update-shared-libraries"
}
]
},
{
"text": "Trying a new strategy with gated versioned releases",
"facts": [
{
"name": "Repository",
"value": "[iris-concourse-resources](https://my.git.com/projects/IRIS/repos/iris-concourse-resources)"
},
{
"name": "Commit",
"value": "[2272145ddf9285c9933df398d63cbe680a62f2b7](https://my.git.com/projects/IRIS/repos/iris-concourse-resources/commits/2272145ddf9285c9933df398d63cbe680a62f2b7)"
},
{
"name": "Author",
"value": "me@company.com"
}
]
},
{
"activityTitle": "Job failed step logs part 1",
"text": "<pre>...very long log text goes here ...</pre>"
}
]
}
Какова фактическая максимальная длина сообщения веб-перехватчика соединителя Microsoft Teams?
На официальной странице об этом не упоминается. В разделе "Отзыв" внизу есть открытый вопрос, касающийся "Ограничения на размер сообщений?" с обратной связью: "В настоящее время мы расследуем это".
1 ответ
Из тестов, которые я провел до сих пор, некоторые наблюдаемые ограничения (если они не зависят от сервера) примерно основаны на полезной нагрузке сообщения JSON (структура и форматирование) от 18000 до 40000 (при длине ниже 18000 никогда не нарушается и выше 40000 всегда нарушается.).
- Пример использования 18000: один длинный текст для раздела
- Пример использования 40000: 600 фактов с очень коротким именем и пустой строкой в качестве значения
И удаление фрагмента полезной нагрузки JSON и добавление равного количества символов в другое значение JSON не даст вам того же максимума.
Я наблюдал мягкий предел (сообщение усечено, но без ошибок) также на максимальное количество разделов: 10. Отрезки, начинающиеся с 11-го, отбрасываются.