Обходной лист (#7)

Co-authored-by: gorbenko.pavel <gorbenko.pavel@tansu.kz>
Reviewed-on: http://git.tnsu.kz/timur.gorodetskiy/request-portal/pulls/7

src/webparts/requestPortal/features/myRequests/myRequests.service.ts

@@ -1,3 +1,4 @@
+import { SPFI } from '@pnp/sp';
 import { spForSite } from '../../shared/pnp/pnpjs';
 import '@pnp/sp/webs';
 import '@pnp/sp/lists';
@@ -7,8 +8,10 @@ import '@pnp/sp/site-users/web';
 import '@pnp/sp/search';
 import { WebPartContext } from '@microsoft/sp-webpart-base';
 import { getRequestTypes, IRequestType, REQUEST_STATUS } from '../../shared/approval';
+import { effectiveUserEmail } from '../../shared/impersonation';
 import { IMyRequest } from './models/IMyRequest';
 import { IMyRequestsTypeDebug } from './models/IMyRequestsDebug';
+import { traceLinkedTypes, traceResultRows, traceSearchHits } from './searchTrace';
 
 // Список данных «... — данные» → список согласования «... — согласование»
 // (конвенция именования; см. forms/*/provisioning.json и forms/*/approval/provisioning.json).
@@ -22,11 +25,24 @@ const DATA_LIST_SUFFIX = /\s*—\s*данные\s*$/;
 // свежесть); при поиске по тексту эта подстраховка не применяется (см. RequestsTableView).
 const RECENT_MS = 10 * 60 * 1000;
 
-// Сколько строк согласования максимум забираем из Search за один запрос
-// (см. getInvolvedRowsViaSearch). Постраничного перебора здесь нет: набор
-// целиком уходит в слияние и сортировку по дате заявки, поэтому при превышении
-// лимита пишем предупреждение в лог, а не молча обрезаем.
-const SEARCH_ROW_LIMIT = 500;
+// Сколько строк максимум запрашиваем у Search за ОДИН HTTP-вызов — верхняя
+// граница RowLimit самого SharePoint Search REST API. Полный набор всегда
+// собирается несколькими такими вызовами через StartRow (см.
+// fetchAllSearchRows) — это не потолок итогового результата.
+const SEARCH_PAGE_SIZE = 500;
+
+// Абсолютный потолок на суммарное число строк, которые fetchAllSearchRows
+// заберёт за все страницы, — защита от зависания на аномально большом
+// индексе, а не ожидаемый рабочий предел. При достижении пишем предупреждение
+// и возвращаем то, что успели собрать, вместо бесконечного перебора.
+const SEARCH_HARD_CAP = 5000;
+
+// Сколько Id максимум перечисляем в одном REST $filter (`Id eq 1 or Id eq 2…`)
+// при дочитывании полей по найденным через Search элементам (см. loadByIds).
+// SharePoint REST не резиновый по длине URL — несколько сотен ИЛИ уже рискуют
+// упереться в лимит, поэтому набор Id одного типа режется на такие пачки,
+// а не уходит одним запросом целиком.
+const REST_ID_FILTER_CHUNK = 100;
 
 // Сколько последних заявок автора дочитываем через REST в довесок к Search
 // в разделе «Мои заявки» (см. getFreshOwnRowsForType). Это записи ОДНОГО
@@ -41,26 +57,35 @@ const MP_APPROVER = 'TansuSiteApproverOWSUSER';
 // Статус СТРОКИ МАРШРУТА (колонка ApprovalStatus списка «— согласование») —
 // Choice-поле, отсюда суффикс OWSCHCS (подтверждено отладочным перебором
 // 2026-08-06; у Person-полей он OWSUSER, см. MP_APPROVER). Колонку не путать с
-// RequestStatus списка ДАННЫХ — это статус ЗАЯВКИ целиком.
-//
-// Для статуса ЗАЯВКИ (список ДАННЫХ) отдельной managed property здесь
-// НАМЕРЕННО нет: имя для произвольной Choice-колонки в схеме поиска либо надо
-// знать точно, либо угадывать по конвенции — угадали неверно (или колонка
-// после переименования Status → RequestStatus ещё не переиндексирована), и
-// фильтр по статусу молча возвращал 0 заявок. Поэтому статус заявки
-// фильтруется НЕ в KQL, а в памяти после дочитывания реальных полей через REST
-// (см. getOwnRequestsByStatus) — Search там ищет только по надёжному
-// AuthorOWSUSER, статус ни при чём.
+// RequestStatus списка ДАННЫХ — это статус ЗАЯВКИ целиком (см. MP_REQUEST_STATUS
+// ниже).
 const MP_STATUS = 'ApprovalStatusOWSCHCS';
 
+// Статус ЗАЯВКИ (колонка RequestStatus списка ДАННЫХ) — Choice-поле, тот же
+// суффикс OWSCHCS, без префикса группы колонок сайта (поле локальное для
+// списка, как и ApprovalStatus выше). Раньше здесь стояло «угадали неверно,
+// фильтр молча возвращает 0» — перепроверено вручную через
+// /_api/search/query 2026-08-17: и голый запрос по этому свойству, и в
+// связке с Path, отдают счётчики, совпадающие с REST-эталоном (см.
+// getOwnRequestsByStatus). Старый вывод о поломке был артефактом кривого
+// тестового Path (задвоенный сегмент /sites/…), а не реальным ограничением
+// SharePoint — сама схема поиска исправна.
+const MP_REQUEST_STATUS = 'RequestStatusOWSCHCS';
+
+// effectiveUserEmail, а не pageContext напрямую: при отладочной подмене личности
+// (см. shared/impersonation.ts) «мои заявки» и очереди согласования должны
+// отбираться по подменённому сотруднику — иначе подмена показывала бы чужой
+// маршрут в форме, но собственные списки заявок.
 export function currentUserEmail(context: WebPartContext): string {
-  return (context.pageContext.user.email || '').toLowerCase();
+  return effectiveUserEmail(context).toLowerCase();
 }
 
 // Типы заявок, у которых approval-route API уже отдал listId/siteUrl (готовы к чтению).
 export async function getLinkedTypes(context: WebPartContext): Promise<IRequestType[]> {
   const types = await getRequestTypes(context);
-  return types.filter((t) => !!t.listId && !!t.siteUrl);
+  const linked = types.filter((t) => !!t.listId && !!t.siteUrl);
+  traceLinkedTypes(types, linked);
+  return linked;
 }
 
 // Что показывать в разделе «На согласовании»:
@@ -269,12 +294,12 @@ async function indexApprovalsForType(
     // SharePoint REST — резолвим email в числовой Id пользователя (как и везде в
     // проекте, см. ensureUser) и фильтруем по TansuSiteApproverId.
     //
-    // ApprovalStatus в $filter НЕ используем: подтверждено на практике — фильтр
-    // вида `ApprovalStatus eq 'На согласовании'` (кириллица в $filter) молча
-    // возвращает 0 строк, даже когда без него те же строки находятся с этим же
-    // значением статуса. Поэтому фильтруем только по TansuSiteApproverId
-    // (числовое значение, проблем нет), а статус сравниваем в JS после
-    // получения строк.
+    // ApprovalStatus в $filter теперь ИСПОЛЬЗУЕМ: раньше здесь считалось, что
+    // кириллица в значении делает такой фильтр ненадёжным, — перепроверено
+    // вручную через REST 2026-08-17 (все три статуса списка согласования дали
+    // точное совпадение с эталоном), теория не подтвердилась. Старый вывод о
+    // поломке был артефактом кривого тестового запроса, а не реальным
+    // ограничением SharePoint.
     const claimsLogin = tokenEmail.indexOf('|') >= 0 ? tokenEmail : `i:0#.f|membership|${tokenEmail}`;
     const approver = await sp.web.ensureUser(claimsLogin);
 
@@ -289,20 +314,20 @@ async function indexApprovalsForType(
       // getInvolvedRowsViaSearch, поэтому решение «моя очередь сейчас» всегда
       // точное, даже когда список кандидатов пришёл из Search.
       const cutoffIso = new Date(Date.now() - RECENT_MS).toISOString();
+      // Статус — прямо в $filter (см. комментарий про ApprovalStatus выше):
+      // REST-довесок сразу отдаёт только нужные строки, без постфильтрации в JS.
+      const statusFilter =
+        statuses.length > 0 ? ` and (${statuses.map((s) => `ApprovalStatus eq '${s}'`).join(' or ')})` : '';
       const recentRows = (await approvalList.items
-        .filter(`TansuSiteApproverId eq ${approver.Id} and Modified ge '${cutoffIso}'`)
+        .filter(`TansuSiteApproverId eq ${approver.Id} and Modified ge '${cutoffIso}'${statusFilter}`)
         .select('Id', 'TicketId', 'ApprovalStatus')
         .top(2000)()) as Array<Record<string, unknown>>;
 
-      // Статусы уходят в KQL: сервер сразу отдаёт только нужные строки,
+      // Статусы уходят и в KQL: сервер сразу отдаёт только нужные строки,
       // а не всё, где пользователь есть в маршруте.
       const searchRows = await getInvolvedRowsViaSearch(context, type, approvalList, statuses);
       const seenIds = new Set(recentRows.map((r) => r.Id));
-      const allRows = recentRows.concat(searchRows.filter((r) => !seenIds.has(r.Id)));
-
-      // REST-довесок берётся по Modified без учёта статуса (кириллица в $filter
-      // ненадёжна, см. выше) — отбор по статусу делаем здесь, на клиенте.
-      stepRows = allRows.filter((r) => statuses.indexOf(r.ApprovalStatus as string) !== -1);
+      stepRows = recentRows.concat(searchRows.filter((r) => !seenIds.has(r.Id)));
     } else {
       // 'involved' — используется ТОЛЬКО для текстового поиска (см.
       // getPendingApprovalIndex/searchMyRequests) — здесь важна не мгновенная
@@ -401,7 +426,9 @@ async function getInvolvedRowsViaSearch(
       .expand('RootFolder')()) as { RootFolder?: { ServerRelativeUrl?: string } };
     const relUrl = rootFolder.RootFolder?.ServerRelativeUrl;
     if (!relUrl) return [];
-    const approvalListAbsUrl = `${siteOrigin(type.siteUrl as string)}${relUrl}`;
+    // Слеш на конце обязателен: без него префикс …/Lists/List1 совпадает и с
+    // путями элементов …/Lists/List10 (см. listPathPrefix).
+    const approvalListAbsUrl = `${siteOrigin(type.siteUrl as string)}${relUrl.replace(/\/+$/, '')}/`;
 
     const sp = spForSite(type.siteUrl as string, context);
     const pathClause = `Path:"${approvalListAbsUrl}*"`;
@@ -411,29 +438,24 @@ async function getInvolvedRowsViaSearch(
     }
     const kql = clauses.join(' AND ');
 
-    const results = await sp.search({
-      Querytext: kql,
-      RowLimit: SEARCH_ROW_LIMIT,
-      SelectProperties: ['ListItemID'],
-      TrimDuplicates: false,
-    });
-
-    const total = results.TotalRows || 0;
-    const ids = (results.PrimarySearchResults as Array<Record<string, unknown>>)
+    const hits = await fetchAllSearchRows(sp, kql, ['ListItemID'], `«${type.name}»`);
+    const ids = hits
       .map((r) => Number(r.ListItemID))
       .filter((id) => !isNaN(id) && id > 0);
 
-    if (total > SEARCH_ROW_LIMIT) {
-      console.warn(
-        `[Текущие заявки] «${type.name}»: Search вернул ${total} строк, взяли первые ${SEARCH_ROW_LIMIT} — остальные не попадут в выборку`
-      );
-    }
     if (ids.length === 0) return [];
 
-    return (await approvalList.items
-      .filter(ids.map((id) => `Id eq ${id}`).join(' or '))
-      .select('Id', 'TicketId', 'ApprovalStatus')
-      .top(ids.length)()) as Array<Record<string, unknown>>;
+    // Id режем на пачки — тот же предел длины URL REST $filter, что и в
+    // loadByIds (см. REST_ID_FILTER_CHUNK).
+    const chunks = await Promise.all(
+      chunk(ids, REST_ID_FILTER_CHUNK).map((idsChunk) =>
+        approvalList.items
+          .filter(idsChunk.map((id) => `Id eq ${id}`).join(' or '))
+          .select('Id', 'TicketId', 'ApprovalStatus')
+          .top(idsChunk.length)()
+      )
+    );
+    return (chunks as Array<Array<Record<string, unknown>>>).reduce((all, r) => all.concat(r), []);
   } catch (e) {
     console.error(
       `[Текущие заявки] «${type.name}»: Search по списку согласования не сработал:`,
@@ -508,10 +530,64 @@ export interface IOwnRequestsPage {
 }
 
 const PAGE_SIZE = 20;
-// Сколько заявок максимум перечисляем в KQL при поиске среди уже отобранных
-// (см. filterPendingByQuery) — иначе строка запроса станет неподъёмной.
+// Сколько заявок-кандидатов максимум перечисляем в ОДНОМ KQL-запросе при
+// поиске среди уже отобранных (см. filterPendingByQuery) — не потолок
+// итогового результата, а размер чанка: кандидатов режем на такие пачки и
+// прогоняем каждую отдельным запросом, чтобы строка запроса не разрослась
+// до неподъёмной, но при этом ни один кандидат не терялся.
 const KQL_ID_LIMIT = 300;
 
+function chunk<T>(items: T[], size: number): T[][] {
+  const result: T[][] = [];
+  for (let i = 0; i < items.length; i += size) {
+    result.push(items.slice(i, i + size));
+  }
+  return result;
+}
+
+// Собрать ВЕСЬ результат Search по запросу, а не одну страницу: сам
+// SharePoint Search REST API ограничивает RowLimit одного вызова (см.
+// SEARCH_PAGE_SIZE), поэтому при большом совпадающем наборе перебираем
+// StartRow, пока индекс не перестанет отдавать новые строки или пока не
+// упрёмся в SEARCH_HARD_CAP (аварийный потолок, а не ожидаемый лимит — при
+// его достижении пишем предупреждение и отдаём то, что успели собрать).
+async function fetchAllSearchRows(
+  sp: SPFI,
+  kql: string,
+  selectProperties: string[],
+  label: string,
+  sortList?: Array<{ Property: string; Direction: number }>
+): Promise<Array<Record<string, unknown>>> {
+  const rows: Array<Record<string, unknown>> = [];
+  let startRow = 0;
+
+  for (;;) {
+    const results = await sp.search({
+      Querytext: kql,
+      RowLimit: SEARCH_PAGE_SIZE,
+      StartRow: startRow,
+      SelectProperties: selectProperties,
+      TrimDuplicates: false,
+      ...(sortList ? { SortList: sortList } : {}),
+    });
+
+    const page = results.PrimarySearchResults as Array<Record<string, unknown>>;
+    rows.push(...page);
+    const total = results.TotalRows || 0;
+    startRow += page.length;
+
+    if (page.length === 0 || startRow >= total) break;
+    if (rows.length >= SEARCH_HARD_CAP) {
+      console.warn(
+        `[Текущие заявки] ${label}: индекс отдал ${total} строк — забрали только первые ${rows.length} (аварийный потолок)`
+      );
+      break;
+    }
+  }
+
+  return rows;
+}
+
 function siteOrigin(siteUrl: string): string {
   const match = /^https?:\/\/[^/]+/.exec(siteUrl);
   return match ? match[0] : siteUrl;
@@ -521,6 +597,24 @@ function listAbsUrl(type: IRequestType): string {
   return `${siteOrigin(type.siteUrl as string)}${type.listId}`;
 }
 
+// Префикс пути для KQL-условия Path и для сопоставления хитов с типом.
+//
+// Обязательно СО слешем на конце: адреса списков в этом сайте отличаются только
+// номером (…/Lists/List1, …/Lists/List10), и «голый» префикс List1 совпадает с
+// путями элементов List10. В KQL это притягивало чужие элементы, а при разборе
+// ответа хит уезжал в первый подошедший тип — заявки «Обходного листа»
+// приписывались списку List1, дальше их Id искались не в том списке и строки
+// молча исчезали из выдачи.
+function listPathPrefix(type: IRequestType): string {
+  return `${listAbsUrl(type).replace(/\/+$/, '')}/`;
+}
+
+// Хит принадлежит типу, только если путь элемента лежит ВНУТРИ списка —
+// сравнение по границе сегмента, не по «голому» началу строки.
+export function pathBelongsToList(path: string, type: IRequestType): boolean {
+  return path.toLowerCase().indexOf(listPathPrefix(type).toLowerCase()) === 0;
+}
+
 // KQL не терпит спецсимволов в свободном терме — оставляем буквы (лат./кир.),
 // цифры и пробелы. (без \p{L} — целевой ES-таргет проекта его не поддерживает)
 function sanitizeForKql(text: string): string {
@@ -542,23 +636,26 @@ function freeTextClause(query: string): string | undefined {
 //
 // Дедуп по (тип, Id) — ЗДЕСЬ, а не у вызывающей стороны: во всех запросах
 // стоит TrimDuplicates: false (нужно, чтобы найти черновики и «свои» копии —
-// стандартная дедупликация Search иногда схлопывает и их), а без неё индекс
-// может вернуть один и тот же элемент несколькими хитами (переиндексация,
-// несколько «версий» в crawl). Раньше хиты превращались в строки один-в-один,
-// и дубликат из индекса становился дубликатом строки в таблице — с одинаковым
-// React-ключом, то есть видимым «залипанием» одной и той же заявки дважды.
+// стандартная дедупликация Search схлопывает по содержимому, а не по Id, и
+// вместе с ними может случайно схлопнуть две по-настоящему разные, но похожие
+// заявки), а без неё индекс может вернуть один и тот же элемент несколькими
+// хитами (переиндексация, несколько «версий» в crawl). Раньше хиты
+// превращались в строки один-в-один, и дубликат из индекса становился
+// дубликатом строки в таблице — с одинаковым React-ключом, то есть видимым
+// «залипанием» одной и той же заявки дважды.
 function hitsToEntries(
   results: { PrimarySearchResults: unknown[] },
   types: IRequestType[]
 ): Array<{ id: number; type: IRequestType }> {
-  const urls = types.map((t) => ({ type: t, url: listAbsUrl(t).toLowerCase() }));
   const seen = new Set<string>();
   return (results.PrimarySearchResults as Array<Record<string, unknown>>)
-    .map((r) => ({ id: Number(r.ListItemID), path: String(r.Path || '').toLowerCase() }))
+    .map((r) => ({ id: Number(r.ListItemID), path: String(r.Path || '') }))
     .filter((h) => !isNaN(h.id) && h.id > 0)
     .map((h) => {
-      const matched = urls.filter((u) => h.path.indexOf(u.url) === 0)[0];
-      return matched ? { id: h.id, type: matched.type } : undefined;
+      // Сравнение по границе сегмента (см. listPathPrefix): при «голом»
+      // indexOf хиты List10 доставались типу List1 — тому, что раньше в массиве.
+      const matched = types.filter((t) => pathBelongsToList(h.path, t))[0];
+      return matched ? { id: h.id, type: matched } : undefined;
     })
     .filter((e): e is { id: number; type: IRequestType } => !!e)
     .filter((e) => {
@@ -571,6 +668,11 @@ function hitsToEntries(
 
 // Дочитать поля заявок по найденным Id (Search отдаёт не все колонки, и для
 // кастомных полей нет гарантии, что они проиндексированы как managed property).
+//
+// Id одного типа режем на пачки REST_ID_FILTER_CHUNK: теперь, когда Search
+// собирает результат целиком (см. fetchAllSearchRows), их может набраться
+// заметно больше сотни — один $filter из тысяч «Id eq N or …» упёрся бы в
+// предел длины URL SharePoint REST.
 async function loadByIds(
   context: WebPartContext,
   entries: Array<{ id: number; type: IRequestType }>,
@@ -587,16 +689,21 @@ async function loadByIds(
   await Promise.all(
     Array.from(idsByType.entries()).map(async ([type, ids]) => {
       const sp = spForSite(type.siteUrl as string, context);
-      const rows = (await sp.web
-        .getList(type.listId as string)
-        .items.filter(ids.map((id) => `Id eq ${id}`).join(' or '))
-        .select('Id', 'Title', 'RequestStatus', 'Created', 'Author/EMail', 'Author/Title')
-        .expand('Author')
-        .top(ids.length)()) as Array<Record<string, unknown>>;
-      rows.forEach((r) => {
-        const author = r.Author as { EMail?: string; Title?: string } | undefined;
-        byKey.set(`${type.id}-${r.Id as number}`, toMyRequest(r, author, type, kind));
-      });
+      const list = sp.web.getList(type.listId as string);
+
+      await Promise.all(
+        chunk(ids, REST_ID_FILTER_CHUNK).map(async (idsChunk) => {
+          const rows = (await list.items
+            .filter(idsChunk.map((id) => `Id eq ${id}`).join(' or '))
+            .select('Id', 'Title', 'RequestStatus', 'Created', 'Author/EMail', 'Author/Title')
+            .expand('Author')
+            .top(idsChunk.length)()) as Array<Record<string, unknown>>;
+          rows.forEach((r) => {
+            const author = r.Author as { EMail?: string; Title?: string } | undefined;
+            byKey.set(`${type.id}-${r.Id as number}`, toMyRequest(r, author, type, kind));
+          });
+        })
+      );
     })
   );
   return byKey;
@@ -604,9 +711,8 @@ async function loadByIds(
 
 // Последние OWN_REST_TOP заявок автора одного типа обычным REST-ом, в обход
 // Search — сырьё для довеска по свежести (см. getFreshOwnRowsForType).
-// Фильтруем только по AuthorId: статус в $filter не используем, потому что
-// кириллица в сравнении там уже подводила (см. indexApprovalsForType) — отбор
-// по статусу делает вызывающая сторона.
+// Фильтруем только по AuthorId, без статуса: эта функция возвращает ВСЕ
+// заявки автора, отбор по статусу (если он нужен) делает вызывающая сторона.
 async function getOwnRowsForType(context: WebPartContext, type: IRequestType): Promise<IMyRequest[]> {
   try {
     const sp = spForSite(type.siteUrl as string, context);
@@ -728,7 +834,7 @@ export async function searchOwnRequests(
   const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;
 
   const clauses = [
-    `(${types.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
     `AuthorOWSUSER:"${claimsLogin}"`,
   ];
   const text = freeTextClause(query);
@@ -758,17 +864,10 @@ export async function searchOwnRequests(
 // Свои заявки с конкретным статусом ЗАЯВКИ (не строки маршрута) — «Доработка»
 // и фильтр по статусу на вкладке «Инициированные».
 //
-// Статус НЕ уходит в KQL: единственная надёжная managed property здесь —
-// AuthorOWSUSER (стандартное поле автора), а для произвольной Choice-колонки
-// имя managed property надо либо знать из схемы поиска, либо угадывать по
-// конвенции — угадали неверно (или она ещё не переиндексирована после
-// переименования колонки Status → RequestStatus), из-за чего фильтр по
-// статусу молча возвращал 0. Поэтому здесь Search ищет ТОЛЬКО по автору
-// (+ опционально текст) — это находит ВСЕ заявки автора вплоть до
-// KQL_ID_LIMIT, — а отбор по статусу и постраничность делаются в памяти по
-// уже дочитанным через REST реальным полям (см. searchOwnAll/loadByIds).
-// Тот же принцип, что и в filterPendingByQuery: Search сужает набор по
-// надёжному полю, остальное — на клиенте.
+// Статус уходит прямо в KQL через MP_REQUEST_STATUS (проверено вручную
+// 2026-08-17, см. комментарий у константы) — это настоящий серверный запрос
+// с RowLimit/StartRow, как и searchOwnRequests, а не «стянуть всё и
+// отфильтровать в памяти».
 export async function getOwnRequestsByStatus(
   context: WebPartContext,
   types: IRequestType[],
@@ -776,28 +875,52 @@ export async function getOwnRequestsByStatus(
   page: number,
   query: string = ''
 ): Promise<IOwnRequestsPage> {
-  const all = await searchOwnAll(context, types, query);
-  const searchFiltered = all.filter((r) => r.status === status);
+  if (types.length === 0) return { rows: [], totalRows: 0 };
+
+  const sp = spForSite(types[0].siteUrl as string, context);
+  const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;
+  const clauses = [
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
+    `AuthorOWSUSER:"${claimsLogin}"`,
+    `${MP_REQUEST_STATUS}:"${status}"`,
+  ];
+  const text = freeTextClause(query);
+  if (text) clauses.push(text);
+  const kql = clauses.join(' AND ');
+
+  const results = await sp.search({
+    Querytext: kql,
+    RowLimit: PAGE_SIZE,
+    StartRow: (page - 1) * PAGE_SIZE,
+    SelectProperties: ['ListItemID', 'Title', 'Path'],
+    TrimDuplicates: false,
+    // Свежие сверху — как в searchOwnRequests.
+    SortList: [{ Property: 'Created', Direction: 1 }],
+  });
+
+  const totalRows = results.TotalRows || 0;
+  const entries = hitsToEntries(results, types);
+  const byKey = entries.length > 0 ? await loadByIds(context, entries, 'own') : new Map<string, IMyRequest>();
+  const searchRows = entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+
+  if (page !== 1 || query.trim()) return { rows: searchRows, totalRows };
 
   // Довесок по недавним изменениям — только на первой странице и только без
-  // текстового поиска (см. getOwnRequests: тот же принцип — довесок относится
-  // к «показать всё, свежее по дате», а не к результату полнотекстового поиска).
-  let merged = searchFiltered;
-  if (page === 1 && !query.trim()) {
-    const freshRows = (await Promise.all(types.map((t) => getRecentlyChangedOwnRowsForType(context, t))))
-      .reduce((acc, r) => acc.concat(r), [] as IMyRequest[])
-      .filter((r) => r.status === status);
+  // текстового поиска (тот же принцип, что в getOwnRequests): заявку могли
+  // вернуть на доработку только что, индекс мог не успеть её подхватить.
+  const freshRows = (await Promise.all(types.map((t) => getRecentlyChangedOwnRowsForType(context, t))))
+    .reduce((acc, r) => acc.concat(r), [] as IMyRequest[])
+    .filter((r) => r.status === status);
 
-    const seen = new Set(searchFiltered.map((r) => `${r.requestTypeId}-${r.id}`));
-    const onlyFresh = freshRows.filter((r) => !seen.has(`${r.requestTypeId}-${r.id}`));
-    merged = onlyFresh.concat(searchFiltered);
-  }
+  const searchKeys = new Set(searchRows.map((r) => `${r.requestTypeId}-${r.id}`));
+  const onlyFresh = freshRows.filter((r) => !searchKeys.has(`${r.requestTypeId}-${r.id}`));
 
-  const sorted = merged.sort((a, b) => b.created.localeCompare(a.created));
-  return {
-    rows: sorted.slice((page - 1) * PAGE_SIZE, page * PAGE_SIZE),
-    totalRows: sorted.length,
-  };
+  const merged = onlyFresh
+    .concat(searchRows)
+    .sort((a, b) => b.created.localeCompare(a.created))
+    .slice(0, PAGE_SIZE);
+
+  return { rows: merged, totalRows: totalRows + onlyFresh.length };
 }
 
 // Список согласования по типу заявки: Title списка данных → Title списка
@@ -860,17 +983,17 @@ export async function hydrateDecisionComments(
         const approvalList = await approvalListFor(context, type);
         if (!approvalList) return;
 
-        // Фильтруем только по TicketId (числовое поле), статус сравниваем в JS:
-        // кириллица в $filter по Choice-колонке молча возвращает 0 строк —
-        // ровно та же причина, что и в indexApprovalsForType.
+        // TicketId (OR-цепочка) в скобках обязателен: у OData `and` связывает
+        // сильнее `or», без скобок фильтр разобрался бы как
+        // «TicketId eq 1 or (TicketId eq 2 and ApprovalStatus eq …)».
+        const ticketFilter = typeRows.map((r) => `TicketId eq ${r.id}`).join(' or ');
         const stepRows = (await approvalList.items
-          .filter(typeRows.map((r) => `TicketId eq ${r.id}`).join(' or '))
-          .select('TicketId', 'ApprovalStatus', 'Comment')
+          .filter(`(${ticketFilter}) and ApprovalStatus eq '${decisionStatus}'`)
+          .select('TicketId', 'Comment')
           .top(DECISION_COMMENT_ROW_LIMIT)()) as Array<Record<string, unknown>>;
 
         const commentByTicket = new Map<number, string>();
         stepRows.forEach((r) => {
-          if (r.ApprovalStatus !== decisionStatus) return;
           const ticketId = r.TicketId as number | undefined;
           const comment = ((r.Comment as string) || '').trim();
           // Такая строка по заявке одна (и возврат, и отклонение останавливают
@@ -900,6 +1023,11 @@ export async function hydrateDecisionComments(
 // обычным REST). Здесь среди НИХ фильтруем по тексту — только через Search
 // (KQL ограничивается ListItemID этих заявок, текст идёт свободным термом по
 // всем полям), без клиентского REST-матчинга по свежести.
+//
+// Кандидатов режем на чанки по KQL_ID_LIMIT и гоняем каждый отдельным
+// запросом (см. chunk/fetchAllSearchRows) — раньше «лишние» сверх лимита
+// кандидаты молча выпадали из поиска, теперь ни один не теряется, просто
+// уходит несколькими запросами вместо одного.
 export async function filterPendingByQuery(
   context: WebPartContext,
   types: IRequestType[],
@@ -909,34 +1037,35 @@ export async function filterPendingByQuery(
   const text = freeTextClause(query);
   if (!text || rows.length === 0) return rows;
 
-  if (rows.length > KQL_ID_LIMIT) {
-    console.warn(
-      `[Текущие заявки] Поиск среди ждущих решения ограничен ${KQL_ID_LIMIT} заявками из ${rows.length}`
-    );
-  }
-  const candidates = rows.slice(0, KQL_ID_LIMIT);
-
-  const scopeTypes = types.filter((t) => candidates.some((r) => r.requestTypeId === t.id));
+  const scopeTypes = types.filter((t) => rows.some((r) => r.requestTypeId === t.id));
   if (scopeTypes.length === 0) return [];
 
   const sp = spForSite(scopeTypes[0].siteUrl as string, context);
-  const kql = [
-    `(${scopeTypes.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
-    `(${candidates.map((r) => `ListItemID:${r.id}`).join(' OR ')})`,
-    text,
-  ].join(' AND ');
+  const pathClause = `(${scopeTypes.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`;
 
-  const results = await sp.search({
-    Querytext: kql,
-    RowLimit: KQL_ID_LIMIT,
-    SelectProperties: ['ListItemID', 'Title', 'Path'],
-    TrimDuplicates: false,
-  });
+  const found = new Set<string>();
+  await Promise.all(
+    chunk(rows, KQL_ID_LIMIT).map(async (candidates) => {
+      const kql = [
+        pathClause,
+        `(${candidates.map((r) => `ListItemID:${r.id}`).join(' OR ')})`,
+        text,
+      ].join(' AND ');
 
+      const hits = await fetchAllSearchRows(
+        sp,
+        kql,
+        ['ListItemID', 'Title', 'Path'],
+        'Поиск среди ждущих решения'
+      );
+      // ListItemID уникален только внутри своего списка — сверяем пару тип+Id.
+      hitsToEntries({ PrimarySearchResults: hits }, scopeTypes).forEach((e) =>
+        found.add(`${e.type.id}-${e.id}`)
+      );
+    })
+  );
 
-  // ListItemID уникален только внутри своего списка — сверяем пару тип+Id.
-  const found = new Set(hitsToEntries(results, scopeTypes).map((e) => `${e.type.id}-${e.id}`));
-  return candidates.filter((r) => found.has(`${r.requestTypeId}-${r.id}`));
+  return rows.filter((r) => found.has(`${r.requestTypeId}-${r.id}`));
 }
 
 // ---------------------------------------------------------------------------
@@ -956,8 +1085,10 @@ export interface ISearchPage {
   totalRows: number;
 }
 
-// Как searchOwnRequests, но без $skip/$top — сразу весь найденный срез (до
-// KQL_ID_LIMIT). Только Search, без REST-подстраховки на свежесть.
+// Как searchOwnRequests, но без $skip/$top — сразу весь найденный срез
+// (см. fetchAllSearchRows — весь, а не первые KQL_ID_LIMIT: тот лимит здесь
+// больше не действует, это чанк-размер для другой функции, filterPendingByQuery).
+// Только Search, без REST-подстраховки на свежесть.
 export async function searchOwnAll(
   context: WebPartContext,
   types: IRequestType[],
@@ -968,24 +1099,25 @@ export async function searchOwnAll(
   const sp = spForSite(types[0].siteUrl as string, context);
   const claimsLogin = `i:0#.f|membership|${currentUserEmail(context)}`;
   const clauses = [
-    `(${types.map((t) => `Path:"${listAbsUrl(t)}*"`).join(' OR ')})`,
+    `(${types.map((t) => `Path:"${listPathPrefix(t)}*"`).join(' OR ')})`,
     `AuthorOWSUSER:"${claimsLogin}"`,
   ];
   const text = freeTextClause(query);
   if (text) clauses.push(text);
   const kql = clauses.join(' AND ');
 
-  const results = await sp.search({
-    Querytext: kql,
-    RowLimit: KQL_ID_LIMIT,
-    SelectProperties: ['ListItemID', 'Title', 'Path'],
-    TrimDuplicates: false,
-  });
+  const hits = await fetchAllSearchRows(sp, kql, ['ListItemID', 'Title', 'Path'], 'Свои заявки');
+  const results = { PrimarySearchResults: hits, TotalRows: hits.length };
 
 
+  traceSearchHits('Свои заявки', kql, types, results, listAbsUrl);
+
   const entries = hitsToEntries(results, types);
   const byKey = entries.length > 0 ? await loadByIds(context, entries, 'own') : new Map<string, IMyRequest>();
-  return entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+  const rows = entries.map((e) => byKey.get(`${e.type.id}-${e.id}`)).filter((r): r is IMyRequest => !!r);
+
+  traceResultRows('Свои заявки', types, entries, rows);
+  return rows;
 }
 
 /**