Восстановление после тайм-аута при использовании Определение исходного оператора без частичных результатов

Восстановление после тайм-аута при определении оператора начинается с разделения успешно выполненного запроса и неопределенного события передачи данных.

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

Определите, на каком этапе произошел сбой

Сервис Определение исходного оператора предоставляет данные об операторе, которому изначально был выделен диапазон номеров, типе номера и географии распределения. Завершенный ответ может содержать пустые поля оператора, что означает, что эти значения были недоступны в рамках данного запроса. Это отличается от тайм-аута службы, отклонения формата E.164 или сбоя соединения на стороне клиента. Процедура восстановления должна классифицировать этап сбоя, прежде чем принимать решение об отправке нового запроса.

Начните с записи попытки на стороне клиента: режим запроса, отправленный канонический номер или список номеров, время отправки, факт получения ответа и корректность его обработки приложением. Это предлагаемые диагностические данные, принадлежащие приложению, а не схема ответов провайдера. Защищайте полные идентификаторы и учетные данные в соответствии с политикой логирования вашей организации. Публичный API принимает номера в формате E.164 с префиксом «+» для проверок в реальном времени; отклонение из-за формата должно возвращать процесс на этап подготовки, а не в цикл повторных попыток при тайм-ауте.

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

Используйте таблицу состояний сбоя

Компактная таблица решений помогает поддерживать единообразие операционных меток. Приведенные ниже действия являются рекомендациями для клиентов; они не гарантируют автоматическое поведение повторных попыток в CarrierLookup.

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

Восстановление мультизапроса как единого целого

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

Если получен нормальный ответ на мультизапрос, сверьте итоговые показатели и упорядоченные результаты перед обновлением записей контактов. Отдельные записи exists=false указывают на отсутствие нормального результата для этой позиции, а не на доказательство неверного, отключенного или не имеющего оператора номера. Не копируйте этот флаг в интерпретацию CSV-файла; вывод массовых файлов использует собственный контракт. Сохраняйте статус каждого элемента независимо от полей оператора.

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

Определите политику повторных попыток на основе доказательств и затрат

Повторная попытка — это новая попытка поиска, а не исправление отсутствующих значений в старом ответе. Определите, какие состояния подлежат повтору, сколько попыток разрешает приложение клиента и кто проверяет случаи постоянной неопределенности. Это выбор приложения; не описывайте их как недокументированные ограничения или гарантии провайдера. Избегайте немедленных параллельных повторных попыток, которые конкурируют за общие слоты реального времени учетной записи. Публичный API документирует средства контроля параллелизма, поэтому повторные попытки должны проходить через ту же очередь, что и новые задачи.

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

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

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

Часто задаваемые вопросы

Возвращает ли тайм-аут мультизапроса частичные результаты по операторам?

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

Является ли пустое поле оператора тем же самым, что и тайм-аут?

Нет. Завершенный поиск может иметь недоступные поля оператора и при этом являться завершенным, тарифицируемым результатом.

Что команды должны сохранять перед повторной попыткой?

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

Может ли тайм-аут доказать, что у номера телефона нет оператора?

Нет. Он не дает нормального заключения об операторе, а поиск оператора не устанавливает валидность или доступность номера.

Узнайте больше

Выберите информацию о продукте, которая соответствует следующему шагу в вашем рабочем процессе.

• Просмотреть документацию по продукту →
• Связаться с командой →