backend/Tnsu.ApprovalRoute.Application/Reports/VacancyReportService.cs

@@ -18,6 +18,27 @@ namespace Tnsu.ApprovalRoute.Application.Reports;
 ///
 /// Рекрутёра и даты закрытия вакансии в самой заявке нет — они берутся из парного
 /// списка «— согласование», из строк фазы «Исполнение» (см. ExecutionRow).
+///
+/// ПОЧЕМУ ЗДЕСЬ items REST ПО ПАРТИЦИЯМ, А НЕ SEARCH (разбирались 2026-08-28).
+/// Search выглядит уместнее — один KQL сразу по всем партициям, и отставание
+/// индекса отчёту не критично. Но на этом тенанте ЧАСТЬ нужных полей индекс не
+/// отдаёт вовсе, при том что в самих списках значения есть (проверено поштучно
+/// через REST):
+///   • «Заявка на подбор»: OpenReason, OpenReasonDetails;
+///   • «Прием на работу»: CandidateName, HireDate, ReplacedEmployee;
+///   • «— согласование»: Ticket — Lookup, managed property не нашлась ни под
+///     одним из разумных имён (TicketOWSTEXT/TicketOWSLKID/TicketId/…).
+/// Префикс группы колонок сайта (TansuSite…, см. tools/sp/README.md) тоже не
+/// помогает — пробовали.
+///
+/// Значит эти поля пришлось бы дочитывать построчно батчами по 100 — и на 1000
+/// заявок Search+дочитка выходит ~46 HTTP-запросов против ~5 у нынешнего REST.
+/// В list view threshold (5000) REST при этом не упирается by design: партиции
+/// режутся на 4900 элементов (ListPartitioning:ItemCountThreshold), то есть ни
+/// один $filter не сканирует больше предела.
+///
+/// Вернуться к Search имеет смысл, только если в Search Schema заведут
+/// работающие managed properties для перечисленных выше полей.
 /// </summary>
 public sealed class VacancyReportService(
     ApprovalRouteDbContext db,