Строка листа 4.7. База клиента бывает на десятки тысяч номеров, и экран
получал её одним куском: замер на 20 000 номерах — 5.09 с и 3.60 МБ в одном
ответе. Стало 0.04 с и 0.01 МБ на страницу.
Что сделано:
· GET /api/sms/contacts отдаёт страницу по 50 номеров и поля страницы
(total / page / per_page / last_page) в том же объекте, где уже жил потолок
загрузки — форму ответа меняли ОДИН раз, в прошлой задаче (В-160);
· больше 200 номеров за один ответ не отдаётся НИКОМУ (В-166): иначе
постраничность обходится параметром ?per_page=100000 и обязательство
«не грузится целиком» остаётся невыполненным;
· экран показывает «Всего номеров в базе: N» и листалку, страницу берёт у
сервера, а не режет список у себя.
Живой прогон под боевой ролью нашёл то, чего не видел ни один из шести
зелёных тестов (В-167): вторая страница отдавала ТЕ ЖЕ номера, что первая —
paginate() брал номер страницы из глобального запроса приложения, а не из
переданного в метод. По HTTP это одно и то же, поэтому тесты через getJson
врали хором. Номер страницы читается явно; прибор — тест, зовущий метод так
же, как живой прогон.
Двух мест план не касался вовсе, оба про враньё экрана:
· удаление номера убирало строку только на экране — при страницах осталось бы
49 из 50, «всего» не менялось бы, а номер со следующей страницы не
подтягивался (В-164); теперь страница перечитывается, а опустевшая
последняя отступает на шаг назад;
· после загрузки человек оставался на прежней странице и не видел ни одного
своего нового номера при надписи «Добавлено: N» (В-165) — теперь возвращаем
на первую страницу, где эти номера и лежат.
Проверено: ClientSms 305/305, приём лидов 17/17, фронт 1694 + 3 пропущенных,
phpstan 2 чужие давние, vue-tsc 5 чужих давних, pint чисто. Восемь вырезов,
каждый покраснел там, где вырезан. В браузере: 50 строк, «Всего номеров в
базе: 20 000», листалка 1…400, переход на вторую страницу уходит запросом
?page=2 (ответ 9.6 КБ). Стенд возвращён и сверен со снимком до работы.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Строка листа 4.6 состояла из двух половин, и вторая («десятки тысяч
проходят и не падают») не выполнялась вовсе: каждый номер писался
отдельным запросом — 20 000 номеров стоили 25 278 запросов и 41 секунду.
Теперь пишем пачками по 1000 одним upsert: 23 запроса и 3.5 секунды.
Оплаченный ДаДатой оператор при повторной загрузке не стирается, дубли
внутри одной загрузки не роняют её, база не задваивается.
Потолок: колонка client_sms_settings.max_upload_phones (миграция
2026_08_01_100800, схема v9.20), по умолчанию 50 000, правится владельцем
в админке в границах 1 000…100 000. Сверх потолка загрузка отклоняется
целиком — частично загруженная база хуже незагруженной — и человек видит
оба числа. Экран говорит потолок ДО загрузки, числом с сервера.
Потолок спрашивается ПЕРЕД построчной проверкой номеров: иначе отказ на
50 001 номере занимал 20 секунд (замерено живым прогоном), а при верхней
границе запрос успел бы умереть по сроку жизни.
Ответ GET /api/sms/contacts стал объектом {items, max_upload_phones};
мёртвое поле contacts из ответа загрузки убрано.
Проверено: 14 серверных тестов, 2 фронтовых, 8 вырезов (каждый покраснел
там, где вырезан), живой прогон под боевой ролью crm_app_user и в браузере.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Доработки экрана «Моя база» клиентской СМС-рассылки по просьбе владельца:
- Кривые номера больше не выбрасываются молча: uploadContacts/uploadContactsFile
возвращают rejected + rejected_samples, экран показывает «Добавлено: N,
не распознали: M (например: …) — проверьте формат».
- Таблица базы — только «Номер» и «Оператор» (колонку «Имя» убрал).
- Загрузка базы Excel-файлом: сервис ClientSmsPhoneFileReader (phpspreadsheet)
читает первую колонку, пропускает заголовок, номера-как-числа не уходят в
научную нотацию; endpoint POST /api/sms/contacts/file; на экране — выбор файла
и кнопка «Загрузить файл».
- «Скачать пример файла»: ClientSmsBaseExampleWriter + GET /api/sms/contacts/example
— готовый .xlsx с колонкой «Телефон» и образцами номеров.
- Оператор через ДаДату: EnrichClientSmsContactsOperatorJob обогащает добавленные
номера (DaDataPhoneClient.provider) в фоне, под tenant-контекстом (RLS), с
защитой дневного бюджета (DaDataBudgetGuard); сбой ДаДаты не роняет прогон,
оператор остаётся пустым; уже известного оператора не перезапрашиваем.
Тесты: бэкенд ClientSms 130/130, фронт СМС-спеки 63/63 — зелёные; pint чист;
портал пересобран. Синтетические номера 7999… в тестах.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Дмитрий