Нулевой результат при видимых товарах обычно означает расхождение между карточкой, индексом и логикой объединения фильтров. Один атрибут может храниться строкой вместо числа, вариант товара может индексироваться отдельно, а выбранные значения объединяться через AND там, где пользователь ожидает OR. Начинать нужно с фактического поискового запроса.

Возьмите один товар, который обязан находиться, и включайте фильтры по одному. Сохраните нормализованные параметры, сформированный DSL или SQL, версию индекса и документ товара. Первый фильтр, после которого товар исчезает, сильно сужает область поиска.

Что проверить в первую очередь

Начните с одного воспроизводимого сценария. Зафиксируйте точное время, идентификатор объекта, пользователя или операции, версию приложения и последнее известное рабочее состояние. Не меняйте несколько параметров одновременно: один контролируемый шаг должен подтверждать или исключать одну гипотезу. Перед работой с данными и конфигурацией подготовьте резервную копию и проверенный способ отката.

  • Проверьте, опубликован ли товар, доступен ли в регионе и проходит ли условие остатка.
  • Сравните отображаемые характеристики с документом в поисковом индексе.
  • Уточните логику нескольких значений одного фильтра и разных фильтров.
  • Проверьте единицы измерения, регистр, пробелы, локаль и типы числовых полей.
  • Сбросьте скрытые параметры URL, сортировки и ранее выбранной категории.

Почему возникает проблема

Внешний симптом часто появляется дальше по цепочке, чем первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа, фоновой задачи или внешнего API. Поэтому важно проследить данные от источника до результата и найти первую точку расхождения, а не исправлять только последнее сообщение об ошибке.

  • Индекс не обновился после изменения атрибутов или остатков.
  • Фасет строится по родительскому товару, а фильтр применяется к вариантам либо наоборот.
  • Значения одного свойства объединяются через AND вместо OR.
  • Число индексируется как строка, поэтому диапазон сравнивается лексикографически.
  • Пустое значение из формы превращается в обязательное условие.

Пошаговая диагностика

Диагностику проводите на тестовой записи или отдельном окружении. В журналах скрывайте токены, пароли, персональные данные и содержимое документов. Для каждого шага сохраняйте измеримый результат: код ответа, версию записи, идентификатор события, состояние процесса, контрольную сумму или время выполнения. Так можно отличить подтвержденную причину от случайного совпадения.

  • Запишите raw request и итоговый запрос к поиску без персональных данных.
  • Получите документ контрольного товара непосредственно из индекса.
  • Запустите запрос без фильтров и добавляйте каждую clause по очереди.
  • Проверьте mapping, анализаторы и nested-пути для атрибутов и вариантов.
  • Сравните счетчики фасетов до и после post-filter и региональных ограничений.

Как разделить поиск, фильтры и фасеты

Предсказуемая система явно определяет область каталога, текстовый запрос, обязательные бизнес-ограничения и выбранные пользователем фасеты.

  • Бизнес-фильтры публикации, региона и наличия применяются одинаково к результатам и счетчикам.
  • Значения одного фасета объединяются по документированному правилу OR или AND.
  • Числа, даты, ключевые слова и полнотекстовые поля имеют разные mapping.
  • Варианты связываются nested-запросом, чтобы условия относились к одной вариации.
  • Версия документа и время индексации доступны для диагностики.

Как исправить проблему

Исправление делите на небольшие обратимые изменения. Сначала устраните подтвержденную причину, затем повторите исходный сценарий и проверьте соседние функции. Массовое обновление данных запускайте на ограниченной выборке с отчетом и только после сверки расширяйте на весь объем. Не отключайте авторизацию, проверку сертификатов, валидацию или аудит ради быстрого исчезновения симптома.

  • Нормализуйте параметры фильтра на сервере и игнорируйте пустые значения.
  • Исправьте типы mapping и выполните новую индексацию в отдельный индекс с переключением alias.
  • Согласуйте родительскую и вариантную модель атрибутов и остатков.
  • Разделите query, filter и post_filter в соответствии с ожидаемыми счетчиками.
  • Добавьте explain-режим для администратора, показывающий, какое условие исключило товар.

Безопасный порядок внедрения

  • Сохраните затрагиваемые данные, конфигурацию и текущие журналы, затем проверьте возможность реального восстановления.
  • Повторите проблему на тестовом объекте без реальных списаний, рассылок и необратимых изменений клиентских данных.
  • Зафиксируйте изменение в системе контроля версий или журнале работ вместе с причиной, ожидаемым эффектом и планом отката.
  • Проведите тест на нормальном сценарии, ошибочном вводе, повторном запросе, параллельной операции и временной недоступности зависимости.
  • После выпуска наблюдайте полный пользовательский путь, логи и метрики, а не только один успешный запрос.

Как проверить результат

Разовый успешный тест недостаточен. Повторите операцию, проверьте крайние значения, одновременные действия и восстановление после перезапуска или временного сбоя. Для важного сценария сохраните автоматический тест либо короткий регрессионный чек-лист. Итог должен подтверждаться не только интерфейсом, но и состоянием базы, очереди, внешнего сервиса и журналом действий.

  • Контрольные товары находятся по каждому фильтру отдельно и в допустимых комбинациях.
  • Счетчики фасетов соответствуют результатам и выбранной логике.
  • Диапазоны цен и размеров корректны на граничных значениях.
  • Переиндексация не оставляет смешанные версии документов.
  • Одинаковый URL дает стабильный результат на desktop, mobile и API.

Типичные ошибки при исправлении

  • Показывать товар из базы поверх нулевого поискового ответа.
  • Сбрасывать весь индекс без параллельной версии и плана отката.
  • Исправлять только подписи фильтров, не проверяя реальные значения.
  • Смешивать AND и OR случайным порядком параметров.
  • Игнорировать скрытые условия региона, склада, канала продаж и прав доступа.

Как предотвратить повторение

Профилактика строится вокруг явных контрактов, повторяемых релизов и наблюдаемости. Система должна не только работать сейчас, но и позволять быстро увидеть нарушение правила при следующем обновлении, росте нагрузки или сбое внешнего сервиса. Проверки особенно полезно автоматизировать там, где ошибка уже привела к потере времени, данных, денег или заявок.

  • Создайте эталонный каталог с товарами для каждой комбинации атрибутов.
  • Тестируйте генератор поискового запроса отдельно от интерфейса.
  • Мониторьте задержку индексации и долю нулевых выдач по фильтрам.
  • Версионируйте mapping и используйте атомарное переключение индекса.
  • Сохраняйте обезличенный trace для редких нулевых запросов.

Что контролировать после выпуска

  • Количество успешных и ошибочных операций в разрезе версии, канала и типа сценария.
  • Возраст необработанных записей, длину очередей, число повторных попыток и долю окончательных отказов.
  • Расхождение между пользовательским статусом и фактическим состоянием в базе или внешней системе.
  • Появление новых кодов ошибок после релиза и изменение времени выполнения ключевой операции.
  • Сигналы от поддержки и бизнес-метрики, которые могут показать скрытый частичный сбой.

Что подготовить для технического разбора

  • Описание ожидаемого и фактического поведения с точной последовательностью действий.
  • Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
  • Фрагменты журналов до и после ошибки без секретов и персональных данных.
  • Перечень последних изменений и уже выполненных проверок.
  • Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Почему товар виден по названию, но пропадает после фильтра?

Текстовый документ найден, однако одно из точных условий не совпадает с индексированным атрибутом, вариантом или бизнес-ограничением.

Нужно ли полностью переиндексировать каталог?

Только если меняется mapping или данные массово рассинхронизированы. Сначала подтвердите причину на одном документе.

Как фильтровать несколько размеров?

Обычно значения одного свойства объединяют через OR, но правило зависит от задачи и должно быть одинаковым в интерфейсе и backend.

Когда нужна помощь специалиста

Если фильтры обнуляют каталог, я могу разобрать параметры, SQL или поисковый DSL, mapping и модель вариантов, затем исправить запрос и добавить контрольные тесты. Для оценки достаточно проблемного URL и ID товара, который должен попадать в выдачу.